Ervin Weber

Ervin admits to being a hacker, though he won’t say exactly what he’s hacked. His Toggl specialties (all completely legal) are backend and databases.


5 tips on server and service monitoring

This technical blog post is intended for system administrators. If you are not person managing your computer then show little help and appreciation to one who does – pass link to this on,  maybe he/she will get any ideas from following article. 5 tips in short monitor each of  your server/OS vitals, do not care for own services at this step set up notifications for exceptional situations your software, but only exceptional to reduce noise add third-party service monitoring to your public service, to catch possible problems between world and your datacenter require each of your internal services to include “dependency check and report” monitor your backends, checking each service on each backend from each gateway. Get notified for anomalies such as slow or missing responses

Can You Explain What Your Database Is Doing?

According to (my) theory of database query evolution most startups who choose SQL based databases have the following steps of database/query optimization: 1) Using default queries of chosen framework. This may be ActiveRecord for Rails (doing select * from ….) or any other Object-relational mapping (ORM) bridging database and chosen programming language.

Improve Your Tools, Always!

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else — if you ran very fast for a long time, as we’ve been doing.” “A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” (Through the Looking Glass, Chapter 2). It is likely that the Queen was related to some kind of technology industry. Most probably the IT industry. 

Introducing pg_decorator

This is a technical post by our back-end developer and database guru Ervin. Ruby is wonderful, Rails allows rapid prototyping and quick releases. You start a new project, and in a few minutes you already have something to show.  Scaffolds, migrations, scopes and models appear very fast. Everybody is happy until long after the release. But then things start to slow down and you turn your attention to logs. Firstly you double-check  (using bullet for example) that there is no  n+1 queries and everything is preloaded. Later you try to organize things so that only 1 or 2 queries hit the database per http request, maybe offloading user and session handling to in-memory store. Later you offload long operations to background jobs, or maybe even separate applications/scripts. And everything is OK again.