Tankar, idéer och reflektioner
“If you don’t remember that, you will regret it.”
1) Systems thinking, improving the whole: the performance of a system depends on how the parts fit, not how the parts perform individually.
2) Removing defects is not the same as system performance improvement – you’ve got to aim for what you want, not focus on what you not want.
3) Creativity is not continuous – doing the right thing (wrong) vs doing the (wrong) thing right.
WebKit is BSD/LGPL so that’s good, although entire application isn’t open sourced (which Firefox and the Mozilla organisation is about) – it’s open enough.
The things that bothers me with Firefox, making me shift again:
Chrome/Chromium has a richer plugin (app) echo system. There’s a lot for Firefox too, but I have the feeling that there are less developers and development traction in that echo system.
I’ve always “simulated” slow connectivity using linux iptables, but found redir package today, which looks promising (given that you want to limit TCP streams).
It’s just awesome. I so wished I’d had these tools when I started my career some 14 years ago. Problems I’ve ran into with Docker:
But “apart” from the stability issue, it’s really nice to run packer inside an lxc (from docker) with the goal of producing vagrant boxes. :-)
These are some of the notes I made for myself during my two day training with Scrum.org and others at Scrum.org HQ. Two mind-blowing days, I assure you!
Agility Path comes in to managers at a solution level, Evidence-Based Management addresses the thought level. (If you haven’t heard about it, it’s essentially the next move in trying to improve the profession of software development.)
What do you want to accomplish & how do you want to measure it?
Metrics for improvement, not performance.
Elevating empiricism to business value.
Measuring input, is not output – what do you actually get from this investment?
Success for an Engagement Manager? Help bring relevant metrics, bc of relevant reasons.
Fick en fråga av en vän om detta med varför jag ger så “låga betyg till alla filmer på IMDb“. Här är mitt svar, typ:
Found this on the internetz – a nice litlle basic check list.
1. Avoid Alliteration. Always.
2. Prepositions are not words to end sentences with.
3. Avoid clichés like the plague. They’re old hat.
4. Comparisons are as bad as clichés.
5. Be more or less specific.
6. Writes should never generalize.
Seven: Be consistent!
8. Don’t be redundant; don’t use more words than necessary; it’s highly superfluous.
9. Who needs rhetorical questions?
10. Exaggeration is a billion times worse than understatement.
I’m on an old Ubuntu version, and just needed something to dump a Redis value as JSON.
sudo -s
git clone https://github.com/nicolasff/phpredis
cd phpredis
aptitude install php5-dev -y
phpize
./configure && make && make test && make install
echo "extension=redis.so" > /etc/php5/conf.d/20-redis.ini
service apache2 restart
And then
<?php
#
# Serves the JSON clob from Redis
#
header('Content-Type: application/json');
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$data = $redis->get('movie_database');
echo $data;
?>
Idé: Varje halvår startar man om. Man identifierar då axlarna man vill använda sig av, t ex parprogrammering, automatiserade acceptanstest, TDD, backlog refinement, … Jag hade kollat på eXtreme Programming för inspiration till fler axlar, eller om det finns något Software Engineering-dokument för organisationen eller motsvarande.
För varje axel identifierar man sedan fyra – fem “nivåer” av utförande. Det går bra att ha olika antal nivåer. För parprogrammering skulle det kunna se ut såhär:
För TDD:
Och varannan sprint eller så ber man teamet sätt ut ett kryss på varje “axel” som sedan sammanställs till “spider chart”. Dessa sätts upp i en serie så man kan se förändring över tid.
