Friday, December 19, 2014
A Developer Playlist
Labels:
development,
music,
playlist,
programming
Location:
Bergmannstraße, Berlin, Germany
Monday, November 17, 2014
Recent Reads
From the book "The Senior Software Engineer" from David Bryant
Great read and great quote!
I had a code review once where the reviewer took issue with a stylistic decision that I had made. It had nothing to do with the underlying change or the correctness of the system. It was a classic "agree to disagree" situation and, as I was the maintainer of the code base, I kept the change the way I had done it. He complained to my boss, who then directed me to change it. NOT COOL.
You may encounter a similar situation when having your code reviewed. You may find that the reviewer is insistent that you do things "their way". This is a difficult situation, especially if the other developer is either senior to you or experienced.
The first thing you do in this situation is re-think the change. Ask yourself if the reviewer has a point and if there really is something substantially wrong about the code in question. Chances are, the reviewer is right.
If you are not convinced of this, ask the reviewer to explain in more technical terms why you should make the change they are suggesting. Explain that you don't see anything substantially wrong and that, as the code's maintainer, you feel your style should be given more weight. This might either defuse the situation or lead to a deeper discussion of why the code is problematic.
In the end, the reviewer may just forget about your code, but if the person is persistent and present roadblocks, you might need to just make their suggested changes just to move on. In the end, its more valuable to ship your code than to "be right" in a code review. If you end up taking this route, I would recommend you avoid including this person in future code reviews.
Great read and great quote!
Location:
Bergmann Street, Berlin, Germany
Wednesday, July 30, 2014
Monday, May 26, 2014
seconds_until_end_of_day expires for Cache in Rails
A colleague of mine had to cache some html until the end of the day but found it difficult because cache expects
So we now have
But patching
http://apidock.com/rails/v4.0.2/Time/seconds_until_end_of_day
expires_in
which is relative. We cant pass an absolute Time.now
:PSo we now have
seconds_until_end_of_day
in 4.0.2
, but we use Rails 3
:(But patching
Time
is simple
def seconds_until_end_of_day
end_of_day.to_i - to_i
end
http://apidock.com/rails/v4.0.2/Time/seconds_until_end_of_day
Labels:
3.2,
cache,
rails,
seconds_until_end_of_day
Tuesday, April 29, 2014
Observers and Migratios
The past day we created a model migration and then added an observer for the model after the migration. Surprisingly, the observer (now added in the application.rb file) was loaded first by environment which then checks for the model and tries to fire a DB query for columns.
This fails and therefore the migration does not go through.
So for future reference, always migrate first and then add the observer!
This fails and therefore the migration does not go through.
So for future reference, always migrate first and then add the observer!
Location:
Bergmannstraße 26, 10961 Berlin, Germany
Friday, March 28, 2014
Chuck Norris Hubot
I stumbedupon an API which spits out random Chuck Norris Jokes and I ended up writing a smal hubot for this :)
The API points to http://api.icndb.com/jokes/random
Try it out Chuck Norris Hubot
Labels:
chucknorris,
coffeescript,
hubot,
joke
Location:
Bergmannstraße, Berlin, Germany
Monday, March 10, 2014
Caching Simple Navigation
Morale: Simple Navigation is not that simple
We, in our firm, have different types of user navigation for different types of users. We wanted the flexibility of creating our navigation from the backend(rails) so that there is just one file to maintain with all configurations. Simple Navigation works great in this aspect.
The configuration is complex, but is absolutely generic. We have a couple of navigations to start with, for the normal application and when a user visits the application via the iPad.
The navigation for the normal user takes more than 500ms to render. NOT GOOD! We decided on caching the html. For this we need to split the navigation yet again. With respect to logged in users. Therefore we now have 4 types of navigation, loggedout-normal, loggedin-normal, loggedout-iPad, loggedin-iPad.
We also had some badges on the navigation for unopened items. The next step was to remove these from the navigation file. We created a notifications controller and wrote a small javascript, which takes data from the json response of the show method of this controller, and updated the corresponding sections in the navigation.
Now came the hard part. Caching.
We need to define keys for the Caching itself first.
For a logged out normal user, this would be quite straight forward. Get the locale of the navigation bar. All the users with the same locale got the same navigation bar.
For logged out normal users it would be a little tricky. We have some user specific stuff in the navigation bar such as the username. Therefore, we need the user_id. The user could change his locale and this would trigger a change in the updated_on field on the Users table. This would mean that we need to include this in the key as well. We have a specific link for backend services if the user has admin privileges. For this we need to evaluate the roles of the user. An MD5 has been used to facilitate this.
We need to Cache the non highlighted navigation bar for sanity purposes. Then we plan to highlight the section according to the pages that are rendered. For this we could either create a javascript to add the correct classes or create a stylesheet which highlights the correct section on verification of the correct classes.
We decided to create a stylesheet for this. The stylesheet reads the configuration from the simple_navigation configuration and creates the correct CSS. The file is a LESS file. We extracted the styles to highlight the navigation items into some mixins and used these mixins inside our custom classes.
The next tough part is the sub navigation. While this problem still lurks, we are trying to get away from the sub navigation altogether.
While this post is clearly not technical and is conceptual, this might help some others trying to solve something similar to this.
:)
We, in our firm, have different types of user navigation for different types of users. We wanted the flexibility of creating our navigation from the backend(rails) so that there is just one file to maintain with all configurations. Simple Navigation works great in this aspect.
The configuration is complex, but is absolutely generic. We have a couple of navigations to start with, for the normal application and when a user visits the application via the iPad.
The navigation for the normal user takes more than 500ms to render. NOT GOOD! We decided on caching the html. For this we need to split the navigation yet again. With respect to logged in users. Therefore we now have 4 types of navigation, loggedout-normal, loggedin-normal, loggedout-iPad, loggedin-iPad.
We also had some badges on the navigation for unopened items. The next step was to remove these from the navigation file. We created a notifications controller and wrote a small javascript, which takes data from the json response of the show method of this controller, and updated the corresponding sections in the navigation.
Now came the hard part. Caching.
We need to define keys for the Caching itself first.
For a logged out normal user, this would be quite straight forward. Get the locale of the navigation bar. All the users with the same locale got the same navigation bar.
For logged out normal users it would be a little tricky. We have some user specific stuff in the navigation bar such as the username. Therefore, we need the user_id. The user could change his locale and this would trigger a change in the updated_on field on the Users table. This would mean that we need to include this in the key as well. We have a specific link for backend services if the user has admin privileges. For this we need to evaluate the roles of the user. An MD5 has been used to facilitate this.
We need to Cache the non highlighted navigation bar for sanity purposes. Then we plan to highlight the section according to the pages that are rendered. For this we could either create a javascript to add the correct classes or create a stylesheet which highlights the correct section on verification of the correct classes.
We decided to create a stylesheet for this. The stylesheet reads the configuration from the simple_navigation configuration and creates the correct CSS. The file is a LESS file. We extracted the styles to highlight the navigation items into some mixins and used these mixins inside our custom classes.
The next tough part is the sub navigation. While this problem still lurks, we are trying to get away from the sub navigation altogether.
While this post is clearly not technical and is conceptual, this might help some others trying to solve something similar to this.
:)
Labels:
cache,
fragment-cache,
html,
less,
rails,
ruby,
simple_navigation
Location:
Bergmannstraße 26, 10961 Berlin, Germany
Tuesday, January 7, 2014
Altering a MySQL Table
In a normal world without a lot of records, altering (adding, deleting columns and indices) a table is an easy job. Have a look at the syntax here.
Its essentially creation of a copy of the original table, applying the alter table to the new table and copying row by row until the end of the table is reached. The essential problem with this is that the row by row copy locks the table because we don't want inconsistencies while we copy. I.e. no writes during the copy.
If the table has lots of rows then this becomes a real problem.
It seems that those intelligent guys have a solution to this too.
One Approach :
- Make changes on the Slave and Upgrade the Slave to Master.
Another (Facebook's Way) :
- Create a temporary table which is a copy of the main table
- Apply the changes to the temp table
- Add something which could be used to run changes on the temp table
- Copy data from the main table to the temp table
- Lock the main table
- Replay the changes on the temp table
- Rename the temp table to the original table after renaming the original table to something else
Phew
Thanks to Martin for the star in github
http://www.facebook.com/note.php?note_id=430801045932
https://github.com/soundcloud/lhm
Its essentially creation of a copy of the original table, applying the alter table to the new table and copying row by row until the end of the table is reached. The essential problem with this is that the row by row copy locks the table because we don't want inconsistencies while we copy. I.e. no writes during the copy.
If the table has lots of rows then this becomes a real problem.
It seems that those intelligent guys have a solution to this too.
One Approach :
- Make changes on the Slave and Upgrade the Slave to Master.
Another (Facebook's Way) :
- Create a temporary table which is a copy of the main table
- Apply the changes to the temp table
- Add something which could be used to run changes on the temp table
- Copy data from the main table to the temp table
- Lock the main table
- Replay the changes on the temp table
- Rename the temp table to the original table after renaming the original table to something else
Phew
Thanks to Martin for the star in github
http://www.facebook.com/note.php?note_id=430801045932
https://github.com/soundcloud/lhm
Location:
Bergmannstraße 26, 10961 Berlin, Germany
Subscribe to:
Posts (Atom)