18. September 2010, 09:43, by Silvan Mühlemann
We recently had a discussion about whether to use an ORM tool or code the SQL manually. These are discussions like “Apple vs. Nokia” or “Spaces vs. Tabs“. Very emotional.
You should know that tilllate is using a self-made “ORM” tool: Our ORM framework maps table columns to object properties. But it is agnostic of relationships between tables. And when you want to write a complex query, you end up programming long lines of native SQL. Unreadable.
18. May 2009, 19:39, by Silvan Mühlemann
Because I did not plan to post this article in this blog, it is in German. This should be an exception. Sorry for the English readers.
Die letzte Woche habe ich im Silicon Valley verbracht. Mit einer Gruppe von 12 Leuten haben wir verschiedene Firmen und Organisationen besucht. Hier zähle ich ein paar wild zusammengewürfelte persönliche Eindrücke auf:
- Die zwei heissesten Themen in US-Firmen sind Cloud Computing und Green IT.
- Trotz Green IT ist die durchschnittliche Temperatur im Sitzungszimmer nie höher als 18°. Warme Kleidung ist empfohlen.
- Je niedriger die Temperatur im Sitzungszimmer, desto grösser das Unternehmen.
- Die NASA arbeitet mit Original-Anlagen aus den 50er-Jahren. Gut amortisiert!
- Google ist jene Firma, welche am häufigsten unsere Fragen mit “I cannot comment on that” beantwortet hat.
23. April 2009, 10:34, by Riv-Alain Vakili
The conclusion out of this is:
- We have to optimize our page following yahoo’s findings.
Where to start?
Most of our traffic is generated through the photo album. We analyzed and improved following use-case in terms of loading-speed and responsiveness:
User comes to homepage…
…goes to the a photoalbum…
…clicks through the photos
We then did the following things:
- reduced amount of external scripts (like Google Analytics) or load them after everything else to reduce the dependency on third party hosts
- reduced DOM-operations
- reduced amount of written code by refactoring
- found and removed some common memory leak-patterns
- removed fancy fading-effects as they were useless and took a lot of CPU time
For example on IE7 (50% of our users are using it) we had following improvements:
- time loading and set up the photoalbum decreased from 4.8 to 2.9 seconds
- time switching between thumbnailpages decreased from 1.3 to 0.3 seconds
Once we released the tweaks, the pageviews per visit increased by 20%.
31. March 2009, 21:41, by Silvan Mühlemann
Then you should apply for a job at tilllate.com: Our team is looking for dedicated web developers. You’ll find more information in our job ad:
17. March 2009, 23:33, by Silvan Mühlemann
Four weeks have passed since the last sprint planning meeting. Sprint number two has come to an end. It’s time for the sprint retrospective.
The motivation for the sprint retrospective is:
- Visualize the accomplishment – important for the team morale
- Review any impediments and discuss measures on how to avoid them in the next sprint
Here’s how we are structuring the sprint retrospecives:
The set up
The team and the product owner are allocating one hour in the meeting room. We’re looking at the wall with the task board showing the user stories, the burn down chart and the impediment backlog. This is a big paper with a post it for every impediment encountered during the sprint. We collected the impediments during the bi-weekly scrum meetings (aka daily scrum).
Visualize the achievements
First, I go through all done user stories and say a few words about every story. Time for praising the team. Developers often think “we haven’t achieved anything”. So it’s important to visualize the finished user stories.
1. March 2009, 13:43, by Silvan Mühlemann
I recently had to take over an unfinished project. It was an AJAX control to select multiple friends as you can find it on Facebook.
“It’s 99% complete”, I was told. Yeah, right. I counted 2 story points (without looking at the code). Soon I knew I was too optimistic: Classes calling other classes without logic. Randomly named variables. Data, creation of DOM elements, AJAX calls spread all over the place:
Architecture before refactoring (dramatized)
16. February 2009, 23:14, by Silvan Mühlemann
The first sprint is done! Yes we finally started doing Scrum at tilllate.com*. Well, it’s not exactly how Schwaber and Sutherland would expect it. But our way fits our team. And the acceptance in both the IT team and the rest of the organization is high. It improves motivation and therewith the performance of the team. And that’s what matters.
Sprint planning meeting
14. August 2008, 09:07, by Maarten Manders
This week, there was another webtuesday with lightning talks in Zürich. Leo and I each did a little talk:
“StubidDB” by Leo
Leo still dreaming about dumber databases. His own creation StupidDB might sound familiar to you…
“I’m in Ur Browzerz…” by Maarten
Harry had the idea to locate your users based on their history. I tried it out, giving another 8 minutes of fame to an old and well-known hack. The slides can be found here.
7. August 2008, 18:42, by Maarten Manders
All I needed to do was renaming Trevi_Auth to Tilllate_Auth. Sure, it affected some 41 files, but that’s nothing a little bit of search & replace can’t do. The big headache started when I ran the unit tests.
Shuffle Unit Tests = Fail.
It’s absolutely amazing how much you can mess up unit tests just by changing their order! (Trevi_* comes after Tilllate_*) Everyone knows that tests are supposed to be independent. But we all know how it is. People get lazy, mocks are complicated and testing is boring anyway. And don’t forget about that cool pattern called “Singleton” that we’ve all read about in an inflight magazine!
Obviously we can’t do testing right without getting beaten with a stick. So where’s that stick? Is there a way to reset all static variables in PHP? Is there a PHPUnit hack that forks a separate PHP process for each test?
What is your solution to keep your tests from sticking together like spit ? I’m happy to learn about it!
20. July 2008, 18:41, by Silvan Mühlemann
When displaying an e-mail address on a website you obviously want to obfuscate it to avoid it getting harvested by spammers. But which obfuscation method is the best one? I drove a test to find out. Here are the results:
In 2006 I opened nine different e-mail addresses. On this page I published the nine e-mail addresses. But every address has been obfuscated by a different method. I made sure it’s getting indexed by Google by putting a link to that page on the tilllate.com homepage.
Then I waited 1.5 years (see the original post).
For each e-mail address I counted the amount of spam I received. The amount of spam received started by 21MB (for no obfuscation and a total of over 1800 spam mails) and went down to absolutely no spam.
The following three methods are absolutely rock-solid and keep your addresses safe from the harvesters.