«This class is unusable. I have reprogram it from scratch.» Does that sound familiar to you? – To me it is something I heard over and over again from my developers. Resulting in having five or six implementation of an autocomplete widget. All coexisting in the same code base.
Of course this is wasted time. Redoing the same work is against the DRY principle. Code is not being reused.
Why did they not use component XY and instead reprogrammed its functionality from scratch? Here’s the answers I got:
The worm which made trouble on twitter today is a textbook example of XSS which happens when user input is not properly escaped before being displayed.
Here’s how it worked:
At work 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.
After owning an Motorola StarTac, a Nokia 6110, a Nokia 7110, an Ericsson R380, an Ericsson T68, a Nokia Communicator 1, an HTC Tytn, a HTC S710, a Nokia E71 I finally got an iPhone 4.
That’s definitely a new world for me. As a newbie, I have many questions.
- Why does the Calendar icon always show the current date, while the weather icons sticks to “23° sunny”?
- What reception problems?
- How will I ever use up my 1GB of included data transfer if all apps always warn me so politely when I am about to download a big movie over 3G? Continue reading
“No Laptop.” This was one of the rules which was agreed upon at the Certified Scrum Master course I just took this week. In the first place I was a bit surprised. What if there is an urgent e-mail coming in? What if one topic is not of much interest and I’d like to use the time to get a few tasks done?
An unusual situation for me as nowadays writing e-mails and surfing the web is an accepted activity during meetings or presentations.
Looking back at the the course the rule completely made sense to me. Provided that the meeting is well run (sadly, that’s rarely the case) there are advantages of banning the distraction. Here’s why:
Recently a friend of mine had his first day of work with a new employer. The company was famous to be very employer-friendly. Surprisingly, my friend experienced the opposite: When he came, his boss was not around. No one told him what he had to do. An initial training was not announced. And when he wanted to go to lunch, he found himself alone in the office. He just felt lost at his new workplace. Bad start.
Look at the posts date below. They are old. These are copies of posts I have written for techblog.tilllate.com. So what’s the point of writing this blog?
- I am going to leave tilllate by the end of November and I don’t know what will happen with these posts when I am gone. My posts there deserve a safe haven. Here.
- When someone is googling “Silvan Mühlemann”, currently the first entry is for some boring commercial data register. This blog is supposed to bump that entry from its first position.
- 140 characters sometimes are just not enough.
- I love web design and I felt like trying something new myself.
- www.muehlemann.com was showing an empty page for years now. Such a nice domain needs some content.
- The kids started to go to bed early
and I was bored (well, every parent with kids at the age of mine – 3mo and 2.5yrs – know that I am kidding)
If my kids let me, I will write a new posts. If in August 2011 you still see this entry at this position you know that they didn’t.
I spent last week in the Silicon Valley. In a group of 12 people we have visited some companies and organizations. Here’s a random mix of thoughts I had:
- The hottest topics are Cloud Computing and Green IT.
- Despite Green IT the average room temperature of a meeting room is never higher than 18°.
- The bigger the company, the lower the temperature.
- NASA still works with equipment dating from the fifties
- “I cannot comment on that”, that was the most heard reply during our visit at Google.
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.
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)