Chrome Extensions typically use a background.js script which runs in a separate process that is shared across all tabs. Therefore it is important to know which tab we are currently viewing to be able to interact with it. Luckily many of the API methods that allow us to hook into different life-cycle events specify the tab we are working with.
Dealing with multiple languages (aka locales) can be challenging. Having multiple JSON files with hundreds of keys for each language quickly becomes a maintenance nightmare. It is easy to break, adding/removing a key means you have to edit it across all files and make sure you get the right translations.
Wouldn’t it be great if we can just provide our translators with a link to a spreadsheet and they could just edit everything on their own and leave us to do the things we love?
Switch is a command-line tool to help get a different view of the same data. It allows you to switch between JSON and CSV with a simple command. You can even automate the process so that it does so automatically on the server without your involvement.
Coming to Ruby from Node.js, I was used to always having all my code at the tips of my fingers, right inside my sweet project. When I first came to Ruby, I was glad to have that distraction removed at first. Then about a year and a half or so later I was introduced by my co-worker Adam Maddox to vendoring gems in ruby.
This simple line installs all the gems into the vendor directory instead of the system gem directory. It creates a small file under .bundle/config to let bundler know to go through this new directory to find gems going forward.
Next just add it to the gitignore since we don’t want this in our source control.
Why Would You Ever Want This?
For starters it makes it much easier to debug your code by allowing you to put debug code right into the source code of your gems. Imagine you got a weird validation error and your application code is no where to be found in the stack trace. What do you do? Well if you have things vendored in, you can simply add binding.pry right on that specific line.
Another advantage is that you won’t have to worry about different gems conflicting between ruby versions. Of course it is not a problem since we all know you are already using rbenv ;).
The real gem here is that you will be able to now find where all the magical methods you have been using reside. A simple search in your trusty code editor will reveal the truth!
What happens if you don’t want your searches to yield a ton of results coming from the vendor directory? Well Simply ignore that directory. If you are using sublime it is as simple as adding this to the where clause of your search.
Over the last few months I have been working with Swift to bring a new app to help keep track of my fitness. FitnessKPI is designed to replace the workout journal and make tracking your progress at the gym quick and easy.
In rspec you can typically call the stub method to stub something out. However, this method only works inside an example or a before(:each) block. Try using rspec stubs anywhere else and you get the following error message
The use of doubles or partial doubles from rspec-mocks outside of the per-test lifecycle is not supported.
What if you wanted to temporarily stub out one object inside a before(:all) (since you like those fast test, don’t you 😉 or globally for the entire test suite for say disabling image processing. How would you do that?
Simple, Ruby has this magic word called metaprogramming to rescue us.
Instead of doing:
That is it. We just overwrote the definition of the process method for only this one image instance. No side-effect or stub-code leakage will occur here.
Rails AssetPipeline is a great feautre. However, sometimes it gets really confusing as to where a resource is located. Imagine you had to upgrade a basic library like jQuery UI on an older Rails project. How would you go about doing that if you can’t simply find it as a gem in the gemfile and can’t seem to find it anywhere in the project. More…