There was a point in my life when I was something of an aggressive advocate for open-source and free software. I am still a huge fan of them and do open-source as much code as I can and even contribute to some free software projects, but I’ve also gone back to a number proprietary tools for my day to day tool chain; for instance, this post was at least (partially) drafted in Microsoft Word or Google Docs rather than Libre or Open Office. Probably the most commonly used tool in my belt (and probably everyone else’s) is the web browser and up until today, I pretty much only used Google’s Chrome. An awesome Coder Radio listener named Nicholas replied to an episode from early April suggesting that if I think Google’s forking Webkit to create Blink was a I problem, I should simply vote with usage and move to Firefox, since Mozilla is a bit more dedicated to standards than just about any browser vendor out there. Over the next month, I am going to recount my experiences as a switcher here and see if Chrome really does have such an advantage over the competition. Stay tuned for all the gory details.
Archive for Tools
Coder Radio listeners will know that I recently purchased a Dell XPS 8500 from my local Microsoft Store. Unlike a lot of Cocoa developer, I am not just buying a PC as a glorified Xbox; in fact, I have an Xbox and am very happy with it. This PC is, like my MacBook Air, a working machine. Its mission in life is to develop software or rather be a tool to help me develop software. To that point, a lot of listeners from CR have been interested in what my tool chain on Mac was and I have already received some emails from Windows users asking what I use on the Windows side of life. Before we jump into specific tools, let’s lay some ground work: cross platform support is important to me for most utilities I use; I am very committed to continuing to use Git as my scm of choice; it sounds silly but I like tools that are simple to use and native to the platform; I have no interest in running Cygwin on my Windows machine. Also, I am not going to bother listing the tools that don’t directly influence my dev work or are not Windows specific – for instance I will not be listing Dropbox or Evernote even though I do use them daily.
SourceTree: Though I generally use the command line on Mac for Git, on Windows I prefer to user a GUI and there really isn’t one out there that performs better or is as simple to use as SourceTree. To put it simply, it is the best looking Git client on Windows and is totally free of cost like its Mac counterpart.
Visual Studio: I’ve said it before and I’ll say it again: Visual Studio is a great IDE. Currently, one of my projects is focused on Windows Azure, so Visual Studio was the way to go. So far it rocks.
PowerShell: I have to admit that before Windows PowerShell hit the scene, I always felt that Windows was just a little too GUI focused. After all, on my Mac I can write a little Ruby script or Bash script to solve whatever lame problem I am problem I am having – these problems usually have something to do with improperly named assets from clients (as an aside, please follow the naming conventions I prescribe) that I have loop over and mass rename. Admittedly, I am a PowerShell novice, but so far it rocks I can do just about everything I used to do with a Bash script with roughly the same amount of lines in PowerShell.
That’s it so far. Obviously, I could use a few more tools on the Windows side and if you have any suggestions, please send them my way. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.
If you haven’t been following the indie game development scene, then you might not have heard that Microsoft has confirmed that XNA is dead. This comes as little surprise to me and many in the community, since Microsoft’s recent actions, such as not supporting XNA on WinRT and Windows Phone 8 (arguably their two most important platforms in terms of the consumer market going forward) have made it pretty clear that they haven’t been interested in the technology in some time. Currently, the only places that XNA still lives as far as Microsoft is concerned are Windows Phone 7, an obsolete system, and the Xbox Live Arcade.
Going forward, developers that are already supporting an XNA game have a pretty clear path forward in MonoGame. Migrating to MonoGame will require some work but the upsides are substantial: it is very actively supported by an eager open-source community of developers and it is specifically designed to be cross platform and was designed to be a port of XNA.
If you’re starting a new game development project, it is still a good idea to take a look at MonoGame. MonoGame has not only succeeded in being an adequate port of XNA but has also gone a lot further than XNA as a game development tool and is worth a look in its own right. The idea of a C# easy to use (relative to more traditional game development frameworks) is still a great one and opens the door to game development to a lot of developers who might find a C++ focussed game development tool too intimidating.
To me, this story is less about XNA and game development and more about the danger of basing your project or product on proprietary software. If it weren’t for MonoGame, the XNA developers would be in a poor state right now, since Microsoft was able unilaterally pull support for a technology that they had built their businesses on. If you are being affected by Microsoft terminating support for XNA, then I wish you well and also humbly suggest that you look toward open-source development platforms in the future.
Android developers will know that there are some serious issues of fragmentation on the platform. These issue have been well recorded and, at times, greatly exaggerated. The truth is that in the last year Google has taken great steps toward making the Android development experience more on par with iOS and it could be argued that developing for Android is now as enjoyable as developing for iOS. However, there is still one larger of weakness is the blessed Android development tool chain: a good GUI designer.
Let’s face it — there really aren’t any good GUI designers for relative layouts. Certainly, the one Android developers are provided in Eclipse is a far cry for Apple’s Interface Builder. To be fair, Interface Builder traditionally has not had to deal with relative layouts and there is an element of added complexity in dealing with them. Still, that doesn’t excuse Google’s lackluster tool.
Like many Android developers, I’ve taken to working almost exclusively with layouts by editing the actual XML code. There’s nothing wrong with this, but it can be somewhat tedious when developing a complicated layout, since you have to keep rebuilding your application as you make changes to the layout.
If Google could improve or replace the Android layout tooling, I am confident that we would see more complex and attractive user experience in our Android apps. So, what do you say, Google? Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.
I had a wonderful Thanksgiving this year and, as is common this time of year, friends and family made the normal mentions of things, places, people, or any other sort of noun that they are thankful. Of course, I agree with the most common objects of gratitude: friends, family, etc. However, I got to thinking about work and how thankful I am for the proliferation of open-sourced software. So, I’ve compiled this list of software libraries that I am most thankful for this year.
ASIHTTPRequest: Admittedly, this is a bit older than some of its more popular competitors and there are reasons that one might choose an alternative, but you just can’t be a simple networking interface that includes easy to use caching support. AFNetworking may be the hot new kid on the block, but ASI is still more than adequate for the job. I can’t promise that ASIHTTPRequest will still be my networking framework of choice in 2013 but it has served me well for the last two years and is even a joy to maintain on older apps.
jQuery: Compared to most client-side development, web development is awful. jQuery aims to take pain out of web development and, for the most part, does the job. In the last year, I don’t think I worked on any sites or web apps that did not use at least part of jQuery. I’m sure jQuery will continue to be the ‘go to’ tool for web developers everywhere in 2013.
Rails: Rails has been all over the place this year. I’m very thankful to have had the opportunity to work with it and for it to be introduction to Ruby. For me 2012 was the year of Rails on the backend, however, I doubt that will hold true for 2013. From a consulting perspective, Rails seems to be losing ground to Python-based alternative such as Django and the upstart Node.js. From a more personal perspective, Rails is solving problems I don’t seem to have or rather I have those problems but there are also other issues that it chooses to ignore. Additionally, Rails is going, as is true to its nature, in its own direction (think SASS and Coffeescript) and, in more and more cases, those just aren’t paths I am interested in taking. I have been evaluating alternatives and have come to a decision stay tuned for another post later next week.
There are other projects that I’ve used or use frequently, but these are three that stick out most prominently. Will they all be on next year’s list? Doubtful. Still, I am thankful for them and all the open-source work that makes my job easier and, in some cases, possible. Do you have your own three? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me.
HostGator has been my registrar of choice since I first registered my first domain; however, I have also register a few domains with GoDaddy and (far fewer) with Domain.com. Initially, my needs were simple: give me an easy WordPress or Joomla install and I was happy than a pig in slop. Times, however, have changed. With the exception (somewhat ironically) of this site, I no longer work on WordPress or Joomla sites and instead tend to do more direct web development or ship sites on Rails or some other web development framework. This shift in development platform and time / experience have of course brought a number of other changes with them. For one I am now a big proponent of continuous deployment in the web development space; I’ve been deploying new versions of Fingertip Tech, INC’s website every day since this new redesign.
Unfortunately, the site is hosted on a shared hosting account rather than a ‘real server,’ so I was relatively sure that I was doomed to FTPing my changes up to the host each time I made a change; in my defence, I was developing a small Ruby script that would FTP changes up based on Git commits. As luck would have it, that wasn’t necessary.
As luck would have it HostGator rocks and I was able to get SSH access to my hosting account with a simple phone call and for no additional charge; I’ve dealt with some other hosting providers that covet SSH access and treat it as an add-on.
From there, all you have to do is SSH into your hosting account you will be greeted with something that looks a lot like the a UNIX file system. Once in the file system, you are going to want to put your public SSH key into the remote .ssh directory; if that directory does not currently exist, simply create one.
Now navigate to the www directory for the site you are trying to add Git deployment to. Run the following command ‘git config receive.denyCurrentBranch ignore’. Then navigate to .git/hooks/post-recieve and add ‘GIT_WORK_TREE = ../ git checkout -f’.
On your local repo you will need to add a new remote pointing to your shared hosting directory and you may need to change the SSH port to 2222. Hope this helps someone.
I’ve been looking at some of the older code I’ve had sitting on my various hard drives and Dropbox accounts and realised something: a lot of this code is not that novel. There is nothing wrong with it, but a lot of just solves problems that I find myself having to solve over and over again.
So, I am going to try to open-source as much of this code as possible. There are of course a few conditions to this: I will of course only be open-sourcing code that I actually own (file that under ‘duh’), the code must be theoretically useful in a very general, and I will need to be able to use the code again in proprietary projects.
Basically, what that all boils down to is that I’ll be using the Apache license for most if not all of the code and there won’t be full applications open-sourced.
You can find all of my open-source on my Github. I’ve already started by open-sourcing a simple Ruby script that I use for Mac and iOS development.
If you haven’t read it already, please take a look at my last post for a quick review of the Dell XPS 13’s hardware; this review will take a look at Ubuntu 12.04 on the laptop. A few things of note: Ubuntu was installed via the standard ISO, Dell’s Sputnik PPAs were added via apt-get after the installation was completed, and any and all proprietary drivers are being used on my machine.
The Good: Ubuntu, as always, installs cleanly and easily. The system promptly notified me of a number of updates and provided me with a helpful GUI for installing them. Ubuntu runs stable on the XPS and Dell has done a good job of providing any extra software for the XPS’s hardware via its PPAs. Unity, Ubuntu’s relatively new and somewhat controversial desktop environment, performs almost flawlessly on the XPS 13 and is a welcome update to the somewhat retro GNOME 2 desktop environment that preceded it.
The Bad: The system is for the most part fine, however, there are a few small but noticeable issues. If when the laptop comes out of sleep, adjusting the screen’s brightness does not function until the system is restarted. By default, the user is forced to enter his root password each time the system starts to connect to wifi; this is relatively easy to change for an Ubuntu power user, but the ‘out of the box’ experience is not ideal.
The Ugly: Canonical has done a great job with this latest long term release of Ubuntu and there really isn’t anything ugly about it; though, it is likely that Unity detractors would disagree.
The Verdict: Despite the XPS 13’s abysmal screen and finicky trackpad, it still runs Ubuntu (with the help of Dell’s Sputnik project) quite well.
Listeners of Coder Radio will probably know that my primary mobile production machine is no longer a Macbook Pro but rather a Dell XPS 13 running Ubuntu Linux. I’ve received a lot of emails and questions over social networks asking how the machine is to work in for a full time software developer, so I’ve written up this review of the hardware. To be clear, I will be publishing a second piece on working (more or less) full time in Ubuntu that focuses on the software in the next week or so.
The Good: The Dell XPS 13 is a great looking machine in terms of industrial design. In a lot of ways, it looks a bit more modern than even the Macbook Air which it clearly attempts to emulate. In terms of weight, it comes in just under three pounds. The battery life is more than acceptable and the machine boots and resumes from sleep almost instantly due to its SSD hard-drive. In both Windows and Ubuntu, the XPS feels peppy even with its relatively diminutive four gigabytes of RAM.
The Bad: The trackpad is one of the worst laptop trackpads I’ve worked with in years. On both Windows and Ubuntu, modifications to system settings had to be made in response to the trackpad’s general clumsiness; out of the box the pad seems far too sensitive to accidental swipes and taps from the user’s palm. Another pain point is the fan — it’s loud. Worse still, the fan starts even while doing the most mundane of computing tasks; for example, I currently have this Google Chrome tab with three others and the XChat IRC client open and the fan sounds like the small aircraft of an amature pilot.
The Ugly: The screen is so bad it’s offensive. Where Dell has managed to match or even surpass Apple’s attention to detail in terms of the industrial design of the case, they quickly revert back to the subpar quality we have come to expect from PC manufacturers pinched between the demand for low prices and razor thin profit margins.
The Verdict: The XPS 13 is by no means a bad machine. In fact, it is more than serviceable for most users, however, it would be advisable to wait to see what the next model in the series is like if you do not need a machine today. Does it stack up against the Macbook Air? Sadly, no. Dell’s failings in the screen and trackpad only further highlight the quality of the Air’s screen and elegance of it’s trackpad. If you don’t mind Mac OS X, you’ll be much happier with the Air.
If you have been following me on Google+, you may know that my beloved Macbook Pro had a little accident; I was working late and was extremely tired and I dropped my full mug of coffee directly onto my Macbook. That’s right the entire mug of steaming hot coffee went directly into my almost two thousand dollar laptop. Desperately, I began to dry off the machine and attempted to use compressed air to force out the moisture. I did this for some time but finally had to go to sleep. All I could do was wait. In the morning it became clear that my machine was a doorstop, so I drove to the nearest Apple Store and made a purchase.
The laptop being replaced is a Macbook Pro 13” i7 with 8GB of RAM. By any measure it is a powerhouse for a laptop; full disclosure it has had some trouble with kernel panicking that I believe were due to overheating.
As usual the Apple Store was jam packed, so I had to wait to speak to an employee, but that was fine, since I had not yet decided what to buy. I knew I wanted an Air; my experience with my XPS 13 has sold me on the virtues of SSD’s and frankly traditional spinning drives feel a bit antiquated to me know.
I also looked at the retina model for a few minutes. I can’t deny that it looks very pretty, but the web is not retina yet and the cost is a bit more than I want to spend; I have been going through a Mac laptop about one every eighteen months, so spending over two thousand dollars on a machine seemed foolish to me. Another point regarding resolution is that the Macbook Airs are all higher resolution than the machine that I was replacing and they look stunning.
If you can’t figure it out already, I bought an Air. I had thought that I needed to have the same amount of RAM as my pro, but, having done some research and having worked on my XPS a bit, I came to the understanding that an SSD really makes the most difference for the type of work I do on my Macs: iOS and Mac development.
For the stat minded, I got the 13” Air with 4GB of RAM and the 128GB SSD hard drive. Or in other words the base 13” model. How’s it going? So far so good.