Other Musings - adHoc thoughts on a variety of topics
So I upgraded to El Capitan (10.11) today and immediately experienced some issues with PostgreSQL which failed to start and spawned an error in the log every minute or so.
Turns out the only way to fix this was to change the permissions on the data directory /Library/PostgreSQL/9.3/data in my case to be owned by the postgres user.
A chown -R postgres:admin /Library/PostgreSQL was needed first, then a chmod -R 0700 /Library/PostgreSQL/9/3/data fixed the startup problem.
As google had no other help I've posted this here for others to benefit from
Back in the day, I tried the available Virtual platforms for OS X and settled on Parallels
At the time it seemed to have better features and was very cost effective. I looked at subsequent versions of the alternatives which from time to time had some better features but that wasn't sufficient motivation for me to move.
I've recently been forced to move by a change in Parallels that made it unworkable for me.
I used to have Parallels installed on multiple machines and copied VMs between them as required. I only ever ran one instance of Parallels at a time to stay within the spirit of the license. Recently however a change was made that prevented me from installing updated versions of Parallels on more than one Computer. Given the way I work I was now forced to look at the alternatives of using another VM platform or buying additional licenses
For the cost of an additional Parallels license I was able to buy Fusion and install it an run it on multiple computers simultaneously. The Purchasing process was unbelievably painful as I had an exisiting VWMware account that would not let me but the software but after that the migration was painless.
This is not a slam on Parallels, they make a great product and are entitled to license it as they see fit - but it no longer worked for me and I now have more flexibility as I can keep Fusion running on multiple computers without having to shut it down before starting it on another computer.
(Prompted by the recent Developer Release of OS/X 10.10)
So am I the only one who's not a big fan of the current iOS7 and new 10.10 design style?
Generally I'm not a fan of skeuomorphic design. It can lead to some pretty ugly user interfaces like the Calendar and Notepad apps for OS X, or make application interfaces far busier than they need to be, with things like tape reels that turn for example. Skeuomorphism does help when transitioning from old to new, the desktop metaphor of early GUI designs being an example but it is rapidly overtaken as users adapt to new ways of thinking or interacting.
Apple, in its 2014 keynote introduced further refinements of OS/X and iOS, with even flatter interfaces. Personally I think they've gone too far. Microsoft made similar design choices with Windows 8, removing a lot of the lusciousness of earlier operating systems. I like bold colours, deep and rich icons, graduated transitions and 3 dimensional tricks, believing they present a delicacy of design and interaction that's in deep contrast to the complexity of the interface schemes. None of this should imply that I believe in busy designs with controls littered all over the screen - the simpler the interface is, the better from a user interaction perspective. Flat, featureless interfaces on the other hand disappoint me and I think the current direction of Operating System interface design is taking this too far.
Users need to get ready for a swath of application updates to fit in with the new 10.10 design, and for the time taken to make this happen to detract from the time developers should be spending making their product more useful. Similar amounts of time were wasted with the transition to iOS 7 and I'm not sure that the user experience was improved by any of it.
Audiophool - generally meant as a derogatory term for one who buys into the unscientific claims made by certain manufacturers of audio equipment, specifically accessory items such as cables.
Different analog cables can/do sound different but do they sound better? Many an audiophool will spend ridiculous sums on cables, sometimes more than the equipment it is connected to, claiming it does sound better. I don't buy into this much myself - spending a decent amount on cables (say around $50 for interconnects, more for speaker cable if your speakers cost more than $2,000.) buys better construction and connectors that are unlikely to expand and become loose or degrade with oxidisation.
Digital cables on the other hand shouldn't sound different - they should either work or not work. Construction quality is important, particularly for cables that will be plugged and unplugged a lot but be sensible. One area that may have some basis in measurable truth is USB cables that carry both power and signal - isolating or shielding the power cables may reduce interference of the signal. I'll keep an open mind on this and wait for some published measurements.
An Audiophile, on the other hand is often one who listens to the sound of their equipment, rather than the music playing on it. They usually have beautifully recorded music that to a non audiophile sounds sterile or boring and criticise the quality of recordings. They also seem to change equipment often.
A music lover listens to the music, often has basic or low end hi-fi equipment and a large music collection. Look at a Musicians hi-fi gear and you'll see it often isn't very hi-fi but I'd hardly say they didn't like music.
Everybody is doing Test driven development these days aren't you?
OK all you old school C developers and those of you who write code without a decent test framework can put your hands back down.
Test Driven Development is an incredibly useful paradigm that allow you to produce significantly more robust code and importantly change parts of it with very high levels of assurance you'll identify if the change broke something before you hand it over to the test team (or worse a user) and they start to pick holes in your hard work. If you've written tests from the ground up you'll have exercised all the low level functionality, moved on to more significant chucks of logic and finally to a test case that aligns with a user requirement. A lot of thought will have gone into how the code will be tested before it's written in such a way it can only be tested by hand.
What about the number of tests and should we allow multiple asserts per test?
The literature and body of knowledge has a "one test one assert" as a golden rule. For the most part this makes sense and it certainly should be followed if the test tool being used cannot run all tests if one of the asserts fails! Thankfully Xcode will run all the tests and highlight which Asserts have failed, removing one reason for the rule.
Assume we have some code in a single method or routine that uses conditional logic - Do I have a single test with multiple routines or split into multiple tests?
Let's use an example where I have business logic that says "if the period between two dates covers a leap year the number of days in the year = 366 unless the last date is the end of February". My initial pseudo test cases would be written like:
I think it's better to have a single test case called for example:
with the 3 rules contained in 3 asserts and a method
testLeapYearDaysRule {...}
Our Test Case would then look something like:
- (int) daysInYearBetweenDate1:(NSDate) *startDate andDate2:(NSDate) *endDate {...}
Then the code would be written to make each assert pass. I now only have one place to look to see what tests are being run on that code routine
- (void) testLeapYearDaysRule {
...
yearCount = [aDateCalc daysInYearBetweenDate1:[NSDate dateWithString:@"2012-01-16 00:00:00 +0000"] andDate2:[NSDate dateWithString:@"2012-03-30 00:00:00 +0000"]];
XCTAssertEqual(yearCount, 366, @"yearCount should be 366 is %ld", yearCount);
yearCount = [aDateCalc daysInYearBetweenDate1:[NSDate dateWithString:@"2012-01-16 00:00:00 +0000"] andDate2:[NSDate dateWithString:@"2012-02-29 00:00:00 +0000"]];
XCTAssertEqual(yearCount, 365, @"yearCount should be 365 is %ld", yearCount);
yearCount = [aDateCalc daysInYearBetweenDate1:[NSDate dateWithString:@"2011-01-16 00:00:00 +0000"] andDate2:[NSDate dateWithString:@"2011-03-30 00:00:00 +0000"]];
XCTAssertEqual(yearCount, 365, @"yearCount should be 365 is %ld", yearCount);
}
Source code management tools are an invaluable thing for teams developing software, are essential for commercially released software but can be an annoyance to a solitary developer
Having used a number of large commercial SCM offerings, I can say a bad Source Control Tool is worse than no tool. My least favourite? - ClearCase. One I'll put up with? - TFS but only if I was working in a pure Microsoft shop. My favourite? - git.
git has a large number of positives - it's light weight, can be run from the command line, allows distributed development, allows developers to share their code amongst each other without polluting the main repository, allows (no, encourages) frequent commits (those of us used to tools like VSS or CC probably don't commit frequently enough) and my favourite part - allows developers to branch code when they see fit, not when the tool or the Release Manager sees fit.
git isn't perfect however...
My number one annoyance relates to how I work, with most coding being done on a Mac Pro with 3 monitors (called origin for this article) supplemented by a 17" MacBook Pro for extended periods of coding away from my home office, and a 13" MacBook Pro for coding during travel, for presentations etc.
When I need to work on a laptop I link to the main repository, check out code, commit and then merge back into the main repository - simple enough right?. Unfortunately git prevents me from doing this without additional effort. When committing back into the main repository the dreaded - non bare repository message will appear. I understand why git does this and there are a number of alternatives to make this work but it still annoys me to have to create an new branch on origin: then merge. It's not the end of the world and git's benefits massively offset the annoyances.
Another very minor annoyance is the need to determine where your one source of truth repository will be. A Client - Server tool defines this for you, and often allows the server to be discovered, with git you need to know/be told what the conventions are.
I'm currently lucky enough to have 3 machines; a Mac Pro with 3 monitors, a 17" MBP and a 13" MBP. If I was buying today I would replace the 13" with an 11" Air.
The desktop offers decent ergonomics, has way more power than I require and can be loaded with large Hard Disks plus other expansion cards I don't need. The 17" offers great screen size, a decent keyboard and is fast enough, but weighs too much for comfortable travel (e.g. lugging through airports daily). The 13" is small and light with a quick SSD but has a screen that's too small for me to do development on efficiently. The Desktop wins for ergonomics and productivity - three monitors are better than two,and this remains my preferred setup for development. It isn't portable unfortunately and as I need to do development when travelling, a laptop is essential.
If I could only have 1 machine, it would be the 17" and that was in fact what I had for a few years, but Apple no longer offers this as an alternative. Unfortunately the 15" retina is a bit small on my eyes. I guess I'll have to compromise when the time comes for a replacement. As for screen size - 24" at 1920x1200 is great.
There has been a trend of late for companies to include unwanted and unasked for software from another party when installing software. The economics may be great but the erosion of trust across the user base seems to be ignored. The only valid way of doing this is to specifically ask the user to opt in during the installation process and I wish more companies would do this - I can only wish.
I'm a huge fan of Agile/Iterative/Rapid development. Getting usable code in front of a user quickly achieves rapid feedback, demonstrates value quickly, and provides the bill payers some concrete sense of progress. I'm not a religious fanatic when it comes to Agile practice, it's a useful mechanism but not the only way to skin the cat and other forms of rapid realisation can be just as effective. Even then it needs to be combined with other methods like Test Driven Development to achieve robust and lasting code.
Agile Projects on the other hand I'm less convinced about. The disciplines of setting goals, managing risk etc can't be ignored when running a project. I haven't yet had an Ah-Ha moment that convinces me otherwise. This is contentious amongst the evangelists but history tells us that fanaticism often equals poor results.
A quick reminder on using excel to convert epoc time to a valid excel date time value. =(A1/86400)+25569
By default Safari has a really annoying setting to open the sites/tabs of your last session. This becomes hopelessly slow when you have to wait for them to load or fail to load before you can get to the url bar. The folks at Apple seem to only use a commercial grade connection to the 'net otherwise they'd never have implemented it this way. It used to be easy to turn this off from preferences but now the only way to do it is through the terminal. The right command is:
defaults write com.apple.safari ApplePersistanceIgnoreState YES