Blog concept: Sketchy optimisations

Een artikel, ongeveer 2 maanden geleden geplaatst onder activerecord, database, optimization, orm, performance, query, rails, software & sql.
Blog concept: Sketchy optimisations

Recently a colleague was showing me a concept he was working on. He drafted a change in a fight against so-called 1+n-queries (actually for some reason unknown to me they're called n+1 queries, but my head isn't able to process the problem with just one more query after n queries…); in software development using ORMs like active record it is quite easy to make a single database request objects that when a presented within a view trigger other queries for every object because it has a relationship. Round trips to databases are generally bad as they take time.

For his change, he introduced a new class that we could seemingly reuse, with a just another (a bad code-smell) declaration of relations between objects and whether these should be preloaded when retrieving the primary object. This was in response to indeed a quite bad part of our code that entailed returning objects with counts of selected associations, but instead of counting these in the database, the current code was a…

Ga verder met lezen en/of reageer...

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.

Why I stopped inheriting from ruby’s core Array class

Een artikel, bijna 3 jaren geleden geplaatst onder workbook, gem, rubygems, ruby, inheritance & performance.

Inheritance is considered bad practice for quite some time now (Gamma, Helm, Johnson & Vlissides, 1994). Little did I know when I started the ‘workbook’-project in 2012 (note that I don’t have a computer science background).

The main reason I wrote this workbook-gem was that I wanted the most predictable API for working with spreadsheet data (acting as arrays of arrays), not having to use a different API when reading XLSX or CSV files, nor when writing it.

After learning that inheritance is not always a good thing, I still often thought of a workbook as an array of arrays and hence an exception to the rule. But then I came accross a helpful post by Avdi Grimm: [Why you shouldn’t inherit from Ruby’s core classes (an…

Ga verder met lezen en/of reageer...

Browserondersteuning

Een artikel, ongeveer 3 jaren geleden geplaatst onder browser, Edge, chrome, Firefox, support, mobile, Safari, complexity, quality & performance.

murb hanteert een browser support grading systeem (een idee dat ik ooit heb gekregen van Anselm Hanneman bij het lezen van How to define a browser support level matrix) voor browserondersteuning. We classificeren browsers met een A, B, C of D.

Klasse Omschrijving A Beste gebruikerservaring; alle features werken en weergave is duidelijk. B Alle features werken. Weergave niet altijd optimaal. C Basis functionaliteit werkt (in ieder geval rollen buiten controle (b.v. niet-admin functies)), maar geavanceerdere functies zijn niet altijd beschikbaar. Performance mogelijk niet optimaal. D Wordt niet ondersteund.

B2B projecten

Veelal kantoortoepassingen, complexe schermen, mobile support is een nice to have.

Klasse A Browsers:

  • Google Chrome op Desktop (laatste en op één na laatste versie)
  • Micros…

Ga verder met lezen en/of reageer...

Total cost of ownership valt niet te generaliseren

Een artikel, meer 4 jaar geleden geplaatst onder software, samsaffron, performance, ruby, windows, linux, macos & support.

Om de zoveel tijd komt de term weer terug: 'TCO'. Total Cost of Ownership. Hoeveel het allemaal bij elkaar kost. Het werd in het verleden ondermeer uit de kast gehaald door Microsoft om te waarschuwen voor de kosten die de conversie van naar opensource software met zich mee zouden brengen. Onder TCO wordt dan ook gekeken naar o.a. opleiding, de kosten van licenties, wat de onderhoudsmedewerkers kosten (linux beheerders zouden duurder zijn dan mensen met een microsoft diploma). Wat willekeurige observaties.

Jaren terug genoteerd:

> Grappig om te zien hoe hij met het bijna niets kostende stukje software (van een grote speler) vele uren bezig is om via de complexe interface iets relatiefs simpels voor elkaar te krijgen: een factuur te printen. Straks gaat het zich terugbetalen, zo gaat het argument… maar ik heb er weinig vertrouwen in. Niet in dit geval. Wanneer je werkt met relatief grote bedragen worden er niet zoveel facturen verstuurd. Automatische koppelingen met de bank is …

Ga verder met lezen en/of reageer...

Must do speed optimalizations on nginx

Een artikel, bijna 8 jaren geleden geplaatst onder performance, nginx, server, configuration & cache.

Nginx's default configuration needs a bit of extra configuration (at least on Debian systems) to enable gzip and client side caching. Two very quick wins for better performing web-apps.

Enabling gzip for more content types

Compression makes files smaller. By default only HTML is gzipped, but it it makes sense for quite a list of other file types too. This, however, excludes(!) images, which have their own methods of compression: compression over compression delivers you nothing, and costs you and your end-user a few more CPU cycles.

So find the gzip on; line in /etc/nginx/nginx.conf file (make sure it is not turned off or commented), and either uncomment the gzip_types-line or use this, more complete, line (including svg):

gzip_types image/svg+xml text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Client side caching

Every browser has a cache of its own, …

Ga verder met lezen en/of reageer...

Ruby on Rails is fast

Een artikel, meer 8 jaar geleden geplaatst onder speed, performance, rails, cache, caching, ruby on rails & ruby.

Of course, this title is obviously too blunt. Still, when I see applications being developed on supposedly fast languages such as Java that perform terribly slow it makes me wonder.

Today I had to fix an issue with the slowness of an overview page inside a product I wrote using Rails. I don't like pagination (it's a workaround), but I wasn't expecting pages with over 700 items. The page with items stored in a traditional database was performing somewhat slow: it took about 6 seconds to load. The fix however took me less than half an hour (including searching the docs) from idea to execution and deployment on production (writing this post took me longer):

  old view code to render the item

Passing the item itself to the cache ensures that the cache gets invalidated when the item is updated. The page load it is still kinda heavy, with 500ms of load time, but this is acceptable for its size.

Features like this make Rails not only a super fast way to realise…

Ga verder met lezen en/of reageer...

murb blog