I heard about 10 different ways to organize work flow around pivotaltracker and git and about 5 gems to support that process. All of them seems abusing for me: the outcome of pivotal/git integration is a git commit attached to pivotal story and the rest of conventions like naming branches or merge policy doesn’t make any sense in long time perspective and is just a waste of time in fact.
That’s why I’ve decided to make the most trivial integration that covers this idea and don’t provide additional complexity: Meet git-storyid gem - the only one git/pivotaltracker integration that saves your time.
Here are my slides from Ruby Meditation meet-up in Kiev last weekend. Covers some internals and some features of DelayedJob and Resque. http://x.gusiev.com/background-jobs-frameworks
Last year I had a lot of changes in my career: I had to switch jobs twice while planning to do it only once. Most of the projects I was working on before was about building time wasting features to raise more money for more time wasting features. I wanted to find the right project for myself: A project that brings something good to people. Ruby is extremely good for startups, but easy investments is a decease for most of them in Ukraine. In September I met Allan Grant, CEO of Curebit. Curebit has a great team of sales and marketing people but was lacking great engineers. Allan was the first business guy in my life that was more focused on building product than raising money — build features endless cycle. So we started to work together.
Here are slides I’ve shown on ruby meetup in Kiev. It’s all about my expirience with power hacking rails internals. Give some inside on how ActiveSupport Callbacks and Rails Router are working.
jQuery#on that is not so right but still very effective solution. It allows to fix the problem with initialization of typical events. But initialization is not always about binding DOM events. In more advanced cases it could be wrapping widget class over an element or custom jQuery method call like date-picker.
This is short notes about my experience with full text search based on PostgreSQL and Solr. Solr was primary used with a help of Sunspot gem that was definitely a good idea, but unfortunately caused some drawbacks. PostgreSQL provides full text search out of the box and to my opinion doesn’t need any additional ruby specific tools other than ORM.
Here I am gonna use Chrome browser as an example:
- Open context menu
- Click inspect element.
- Click “Network” tab
- Spawn again an ajax request (at least one click. Sometimes more)
- Click on failed request at Network tab
- Click “Preview” or “Response” subtab
This post shows some examples of how things can go wrong way because of people actions based on assumptions but not on facts. It is more conceptual than practical, so be patient and don’t blame my grammar mistakes too much.
After a dozen performance patches to many gems want to share some practical experience I gain. Tools I’ve picked up was perftools.rb and ruby built-in benchmark library. They are fit well for cases when optimization stays at Ruby level and doesn’t require to fix something in native extensions or dig into IO operations.