How To Add Directory To Path On Ubuntu 14.04

For the past several years, I have been running a Mac as my primary development machine. Recently, I’ve been doing some development on a Ubuntu virtual machine. As per usual with my bouncing back and forth between things, I forgot how to add a directory to my PATH in a Linux Distro. On my Mac, I’m used to having a .bash_login, but I didn’t have that option in this case.

Here’s what I did to add a directory to my PATH in Ubuntu 14.04

sudo vi /etc/environment

Just add your directory to the end of the PATH value, restart your machine and you’re good to go!

How to tell if your Intel-based Mac has a 32-bit or 64-bit processor

I found this information was surprisingly tricky to nail down but finally found a link. I needed to download an SDK where it was important that I downloaded the correct architecture, whether or not my Macbook was 32-bit or 64-bit. After googling around for a bit I finally found a forum post which linked to a site which linked to the page I’m going to share here. It’s a table of all of the different processors Apple puts into their machines and their architecture.

I hope everyone finds this helpful:

dyld: Symbol not found: _mysql_get_client_info

I came across this issue when I generated a new rails app specifying MySQL as the database to use. I am running Mac OS X Yosemite, Ruby 2.1 and Rails 4.

Here’s what I did, I uninstalled the mysql2 gem, then used Brew to install MySQL, then reinstalled the mysql2 gem. Here’s the commands for easy copy and paste:

gem uninstall mysql2
brew install mysql
gem install mysql2

After running those commands, I was able to use MySQL in my Rails projects with no issue.

THREAD WARNING: exec() call blocked the main thread. Plugin should use CordovaInterface.getThreadPool(). – Cordova Plugin Warning

Hey all,

So I came across this today. My plugin needed to add and manipulate views within the Cordova app. The problem is that you can’t do this since in Cordova, the WebView is on the WebCore thread and it can manipulate the UIThread directly. Hence you get this nice error/warning:

THREAD WARNING: exec() call to [pluginname].[method] blocked the main thread for XXms. Plugin should use CordovaInterface.getThreadPool().

The way to fix this is to use the runOnUiThread method from your plugin’s source file. To do this you need to get the main activity of the app. Here’s how you would do that:

  1. this.cordova.getActivity();

From here you would then invoke the runOnUiThread method and pass in a new Runnable object with its own run method. Within the run method is where you would put your code that changes your views. Here’s a snippet to tie it all together:

  1. public boolean execute(String action, final JSONArray inputs, final CallbackContext callbackContext) throws JSONException {
  2.         PluginResult result = null;
  3.         if (action.equals("myPluginMethod")) {
  4.             this.cordova.getActivity().runOnUiThread(new Runnable() {
  5.                 public void run() {
  6.                     callbackContext.sendPluginResult(myMethod(inputs));
  7.                 }
  8.             });
  10.             result = new PluginResult(Status.OK);
  12.         }
  13. }

Hope this helps! Feel free to share your experiences in the comments.

What are symbols in Ruby?

One of the conceptual sticking points I had when learning Ruby was what symbols actually were.

If you’re new to Ruby and/or Rails, you might have come across something like the following:

  1. params[:user_id]

Within a few minutes, you learn or you are told that it’s a symbol. When I was learning Ruby that didn’t mean a lot to me. It took me a bit to really grok them.

A symbol is just a unique way to represent something in code. Think of it like a constant except the value is simply the name of the constant. An example that really helped was the use of Cardinal directions. North, South, East and West don’t really have “values” in the traditional sense. They represent a direction.

For example, if you were coding a game where you control the movement of a player, you might have the following:

  1. def move_player(direction)
  2.   if direction == :north
  3.     player.y -= 1
  4.   elsif direction == :south
  5.     player.y += 1
  6.   elsif direction == :east
  7.     player.x += 1
  8.   else #west
  9.     player.x -= 1
  10.   end
  11. end

In the above code, we don’t care about what the value of North would be. We just care that the player is moving North. That highlights the main purpose of a symbol.

The most common usage of symbols are as keys in a hash. Like the example above, you just need a unique way of being able to identify something.

Here’s another example:

  1. user = {
  2.     :first_name => "Don"
  3.     :last_name  => "Marges"
  4.     :age        => 29
  5.   }

If you contrast this concept with objects in JavaScript, you see that symbols actually make a lot of sense. In JavaScript, the key could be a string which won’t necessarily be unique. Symbols in Ruby are guaranteed to be unique.

Now, you should be warned that you won’t really see an example like the one above in the wild. It is a common practice to use the shorthand of symbols as keys in Ruby. So the above example would look like the following:

  1. user = {
  2.     first_name:  "Don"
  3.     last_name:   "Marges"
  4.     age:         29
  5.   }

I hope this little tutorial has helped you understand symbols a bit more clearly. I didn’t catch on to them as quickly as a should have when learning Ruby because I came from languages like PHP and JavaScript where there isn’t a concept of a Symbol, so I didn’t really have a frame of reference.

Cordova Plugin Creator Ruby Gem

Hey everyone!

I just wanted to announce the release of a Ruby Gem I created!

It was born out of some work I’ve been doing recently with PhoneGap. Essentially, I was creating some plugins that extended the functionality of PhoneGap. For those of you who don’t know, PhoneGap is a tool which Adobe owns that allows you to create Native Mobile Applications using Web Technologies. It’s basically like you’re coding for the browser, except you can release your app in the App Stores. It does this by creating a WebView and running your code within that context.

PhoneGap gives you the ability to write plugins which are native code that you write JavaScript interfaces for. So in your Web code, you can call the JavaScript functions which call into the native code for your plugin.

The drawback is that there is a very specific structure that your plugins must have in terms of configurations and directory structure and it was a pain to have to set it up manually as I would miss a setting and it would prevent my plugin from working.

Using my trusty knowledge of Ruby and creating gems, I created a gem which handled all of the setup for a plugin for you so you can just get to work coding the plugin itself.

Since I’m terrible at naming things, it’s named Cordova Plugin Creator and you can find it on Rubygems here.

Here is the repo for it as well.

Any feedback is appreciated and welcome.

How to fix – TypeError: Uh oh! Arguments to path.join must be strings in Cordova Plugin Remove

I came across a problem while doing some Cordova/PhoneGap Plugin Development that I thought I would share my solution to.

The problem was when using the Cordova Command Line Tool to remove a plugin which was for the iOS and Android platforms I got this error:

TypeError: Uh oh!
Arguments to path.join must be strings

The problem for me was an incorrect setting in my plugin.xml file specific to the Android portion of the plugin. When you create a plugin, a plugin.xml file is necessary to make it work. For each platform you want it to work on, you must add an entry to that file. For example, the Android entry would look like this:

  1. <platform name="android">
  2.         <config-file target="res/xml/config.xml" parent="/*">
  3.           <feature name="MyPlugin">
  4.             <param name="android-package" value="com.mycompany.MyPlugin" />
  5.           </feature>
  6.         </config-file>
  7.         <source-file src="src/android/" target-dir="src/com/mycompany/" />
  8.       </platform>

The issue for me was caused by an incorrect source-file tag, I had the following:

  1. <source-file src="src/android/" />

You MUST have a target-dir attribute specified as well:

  1. <source-file src="src/android/" target-dir="src/com/mycompany/" />

I hope this helps. Feel free to share your solutions or whether this worked for you in the comments.

Primum non nocere – Or one way to be an awesome developer

I bet you’re asking what the phrase Primum non nocere means and what does it have to do with Software Development! Well read on 😉

Primum non nocere is a Latin phrase which is actually taught to med students. It means “First, do no harm”. It’s taught as a means of helping students to realize that sometimes the best course of action is none at all or the least invasive action.

To put the aforementioned phrase into context, let’s say that you suffer from a headache on a particular day of the month for every month of your life. The headache is manageable and just requires you to take it easy for that day. You decide to have your Doctor check it out. Your Doctor tells you to take some Aspirin and lay down until the headache goes away for that day. The Doctor my send you for a test, but if you’re a young person and in good shape, then the last statement will be the most likely outcome.

Now let’s look at this from a Developer’s perspective. When we see a problem with the code we are working on, what is our course of action? Well we would pull down the latest code, create a branch, run the test suite, do some more debugging and finally see what the issue is if we are lucky. Then what do we do? Well, if you’re a student of TDD, you’ll write some tests, make them pass to fix the bug. Then you would see if all of the other tests are passing. If everything looks good you’ll push it up to your repo and submit a pull request.

What typically happens is that your fix introduced some other subtle bug which you may not have expected. So you go through the process again. Then probably again, stacking change upon change. This is in violation of Primum non nocere. In the example visit to your Doctor, did he whip out his bonesaw and start poking around inside your brain? When you have a muscle cramp, does the Doctor cut open your skin to see what’s happening?

The initial problem could have been left alone and you wouldn’t be stuck in this cycle of breaking/fixing. For example, let’s say you populate a list from an external API. From time to time, the request will timeout leaving you with a blank list. So your idea was to check for a timeout and if the request does in fact timeout, then make the request again. You realize that sometimes it could timeout multiple times, so you put it in a loop to keep rechecking. Then you create a way to break out of the loop when the request is successful. After that work you realize that your app is killing the user’s battery by constantly hammering http requests, on an on ad infinitum.

If we were to apply Primum non nocere, one option in the above example would be to simply add some indication to the user that the data was unable to be fetched and to try again and adding a button to refresh but that’s as far as you would go. This would not require any edits to existing code and would be a matter of a Label field and possibly a Button to call the function you have to make the request.

Is it potentially a pain for the user to hit the refresh button? Possibly, but I think we all vastly overestimate how much users actually care about stuff like this. I know that the statement I just made would probably make our inner Steve Jobs blow a gasket, or our bosses or stakeholders put in a recommendation of who should be in the first round of layoffs but hear me out.

When one of the iPhones was having issues of dropped calls because people were holding it a certain way, Steve Jobs famously taught everyone how to fix the problem by holding the phone in the other hand. That’s brilliant! Instead of recalling the phones or issuing a complicated fix, he simply showed people a quick and easy way to fix it that didn’t involve even more issues. Did that affect sales of the iPhone in the least? Absolutely not!

Even though Primum non nocere was meant for Medical Practitioners, I feel that Developers would benefit from its use as well.

The Best Code You Can Possibly Write

How do you write amazingly solid code that covers all edge cases, doesn’t break and is 100% reliable?

That’s simple, you don’t write it at all.

Many times in my career I have been asked to solve complicated issues that resulted in insanely brittle code that frankly I didn’t have any faith or confidence in. Don’t get me wrong, these weren’t complicated issues as in trying to find the largest prime number or some complex Machine Learning algorithm. These issues were along the lines of “hey Don, we need to change that feature so that we can handle when a user uploads a 50gb (even though we told them not to) file while not logged in on a harvest moon from a dial up connection in the middle of Montana.” Issues that had a simple fix…don’t address them.

I have written really insane code that I fought tooth and nail against because these issues were more easily solved by a simple error message. Why is it that we feel we have to cave into the insane edge cases that come up? It’s not like we demand electricians to repair a fuse box for us because we decided to try to fix a blown fuse with toffee and a paper clip! We don’t demand that contractors design a bathroom to protect us against dropping our hair dryer in the toilet! So why are we stuck trying to handle ridiculously outdated browsers and dialup internet connections?

What Project Managers and Stakeholders fail to see is that coding is expensive. Just because what developers do isn’t something you can touch physically, that doesn’t mean costs are any lower or the work is easier. I’ve overheard PMs complain about how there is no room in the budget for things like TDD, but what about handling every single edge case for a form?

If you only accept PNGs for uploads then limit it to PNGs dammit! If they try to upload anything else, stop them and display a message that you only accept PNGs. I know that’s a very trite example, I could give others from my past places of employment but I don’t want to name names out of respect.

I get why it happens. Maybe a potential customer needs your software to be able to support an older environment or their users typically use older machines that can’t support new browsers. If they are non-technical they won’t understand why it can’t be done. That’s why it’s up to us to tell them that it’s not feasible to meet their expectations. We can’t just tell them no and leave it at that. It’s also our responsibility as developers to help them brainstorm other solutions that could meet their needs in other ways. For example, we can’t support anything else other than PNG, but maybe we can put a link to a website that converts your JPEGs to PNGs for free. Or in the other example, suggest that we can develop the website, but we can’t use Canvas animations because IE7 won’t support it and we can use jQuery to do what we can in the way of animation.

What everyone in this business has to remember is that customers use our software because it solves a huge pain point for their business. Focus on solving that pain point! Don’t worry about implementing OAuth so they can login with Facebook if you have a kickass CRM. If you know that users of your CRM mostly use Chrome, and Chrome offers the best way to help you solve their problem then stick a notice up on your sales page saying that you only support Chrome users. Again, if what you are offering them is so targeted and so ridiculously useful to their business for a good price then they won’t care if they have to use Chrome! Don’t believe me? How many organizations are still (STILL!!!) stuck using IE8 because the have a web app that was developed a long time ago and the costs of switching are too high?

All of this comes down to the fact that writing code is very unintuitive for human beings. It’s not something that is natural to us and also the industry is still relatively new. Many of the tools we use are still broken, or have their own fragility or idiosyncrasies. Just think of how many different languages you have to know to get a damned web app up and running! My thought is let’s focus on the code that we HAVE to write to solve the pain point of our customers and no more. If we come up against something and it isn’t directly related to solving that problem, then find a solution that isn’t more code.

I will end off with the famous Space Race problem. During the Space Race, the astronauts needed something to write with. Normal pens wouldn’t work in zero-gravity. NASA spent millions to develop a pen that would work in space. The Soviet Union used a pencil. When faced with a similar problem, always take the pencil, even NASA doesn’t have millions to throw away on pens anymore…

Why WinJS is a glimpse of the future of development

I read an article on WinJS and how it represents a shift towards a Ubiquitous JavaScript world. I definitely recommend you check out the article.

If you haven’t jumped on the JavaScript bandwagon I highly recommend that you do. Even if it doesn’t become your primary language of choice, you should have a deeper understanding of the language. If you’re a beginner then just a cursory Google search on getting started will do. If you’re an Intermediate, I reviewed a book that gets down and dirty with some of the language’s more advanced concepts. You can find that review here.

I’ve touched on this in a previous post, but JavaScript is fast becoming a truly ubiquitous programming language. With tools like PhoneGap and Titanium, you can build mobile apps with JavaScript. The aforementioned WinJS was built to allow developers to build Windows 8 apps, and now Apple is allowing you to write desktop apps in JavaScript. In fact, I have been playing around with the Game Development tool Unity and it allows you to script with JavaScript. Even specific to Web Development, there are a ton of front-end frameworks and with Node.js, Full stack JavaScript development is possible.

I know that JavaScript can be ugly at times, both syntactically and how it works under the hood. But if you combine your JavaScript knowledge with CoffeeScript, I feel that this gives you a nice and easy to read coating around JavaScript.