For some reason, I always thought UUID (or GUID) is a random collection of numbers and characters and randomness guarantees uniqueness. I was pretty sure about the randomness but wasn’t sure that presence of character ‘g’ makes it invalid.
Let’s look at UUID’s definition. UUID is in fact a random 128 bit number and it’s represented using hexadecimal numbers for the sake of readability. Now, let me ask you the same question again:
Is character ‘g’ in UUID valid?
Ofcourse, it’s not valid!
Why?
Because hexadecimal digits don’t include ‘g’. Therefore, a valid UUID should always match:
Do you work with Rails? and is it not a brand spanking new Rails 4, but the older and less-loved, relatively speaking, version?
Then, you must have come across Zeus. It’s pretty handy if you like to test drive your code from outside-in and aren’t scared to venture into the dark and a tad dragging land of integration specs. A usual Zeus workflow is, to start the server first, and then issue commands to the server from the client. Simple!
However, it’s not always like it. You may come across unhelpful error messages, like the following when you start the server:
exit status 1 and then run tests.
</pre>
or
Could not find 'zeus' (>= 0) among 214 total gem(s) (Gem::LoadError)
Both the error messages are very random. Googling the first one will reveal a lot of reasons and ways to fix it, the second one is just a usual gem error message when the gem is missing. In both the cases, I found the reason for the error to be some gems missing from project’s bundle and installing those gems fixes the issue.
So, next time when you pull upstream changes, and Zeus stops working, try running bundler's install command.
Just this week, I found out while trying to run a GET request against Ultrahook, that it doesn’t allow GET requests for security reasons. Maybe give ngrok a try for testing GET requests to your localhost. Webhook calls are POST requests and Ultrahook is as good as gold for that use-case.
Do you care about view markup in your applications?
I do to an extent that anything, even slightly, untidy leaves be deflated. Then one day, I had to work with this AngularJS application, and it was overwhelming, at least.
AngularJS builds on the promise of improving the HTML markup and making it more expressive. However, my first impression was ‘What the hell is this mess!’. My friends, don’t judge a book by its cover, so I still gave my best shot and dug a bit deeper to find out that it’s not bad. To be honest, it’s quite powerful and expressive, and for what it provides with this nice little framework is pretty cool. It’s quite similar to another framework from Google guys, called, Polymer.
I have only touched the surface of AngularJS and once I let my first impressions go, I could see the power beneath the surface. I will be working with it more in the near future and post my thoughts on it again.
Yesterday I had a chance to try out Google Places API. Quite detailed as you’d expect from Google. But, before integrating it with the code you really want to try it out.
When I say try it out, I mean just ‘curl’ an end-point in the terminal and inspect the results. With Google API’s you can create a server key (an API key) and at the time of its creation you specify the IP address for the server where requests would be made from. In order to test it locally, just find out your IP address either using whatsmyipaddress service if you don’t have a static IP address and then just use that IP address as the server address.
Now, you can use any tool (or maybe just use a GET endpoint in your browser) to see the results.