published 3 days ago (15.04.2010 08:26)
Long time no see!
published 3 months ago (10.01.2010 12:20)
Erste Erfahrungen mit AirPort Extreme 802.11n mit 5GHz
Vor kurzem hab ich mir die AirPort Extreme Basisstation von Apple zugelegt. Einstecken und funktioniert, wie gewohnt. Die Standard-Konfiguration hat allerdings lange nicht die maximal mögliche WLAN-Geschwindigkeit. Nach etwas Googlen und Doku lesen stellt sich heraus:
- Die Basisstation kann zwei Drahtloswerke gleichzeitig erstellen. So können unterschiedlich schnelle Endgeräte (Mac, iPhone) in getrennten Netzwerken laufen, die langsamen Geräte bremsen dabei die schnellen nicht aus.
- Die Netze können entweder im gängigen 2.4GHz oder im seltener genutzten 5GHz Frequenzbereich (d.h. weniger Störungen und damit schneller) arbeiten
- die Kanalbreite kann neben den normalen 20Mhz auch doppelt so groß gewählt werden (wide-band)
Um eine bessere Geschwindigkeit für 802.11n-fähige Geräte zu erreichen und weiter das iPhone nutzen zu können hab ich die Station also wie folgt konfiguriert. AirPort Dienstprogramm gestartet und:
- “Manuelle Konfiguration” wählen
- im Reiter “Drahtlos” das Feld “Sendermodus” bei gedrückter Alt-Taste anklicken. Dann erscheinen erweiterte Optionen. Dort einstellen: “802.11n – Nur 5GHz – 802.11b/g/n:
- unter “Weitere Optionen” kann man dem 5GHz Netzwerk einen eigenen Namen geben. So kann man schnell sehen, mit welchem Netz der Rechner verbunden ist. An manchen Stellen heisst es man solle ein anderes Land als Deutschland auswählen um eine höhere Kanalbreite zu erreichen, das hatte bei mir allerdings keinen Effekt. Testweise kann man ein anderes Land einstellen und vergleichen.
- Die Station neu starten. Dann das WLAN-Statusicon (rechts oben am Desktop) bei gedrückter Alt-Taste anklicken. Jetzt sollte in erkennbar sein, dass 802.11n aktiv ist und das 5GHz Band genutzt wird:
Ein Paar Warnungen am Ende:
- die Geschwindigkeit der 5GHz-Verbindung ist sehr unterschiedlich. Gestern habe ich ca. 80 Mbit/s erreicht, gerade eben ist die Geschwindigkeit unterirdisch schlecht (< 1 Mbit/s). Im 2.4GHz Netz sind es gerade 16 Mbit/s. Nach Aus/Einstecken der Station erreicht sie wieder die volle Geschwindigkeit. Woran das liegt, konnte ich nicht herausfinden.
- wenn sowohl 5GHz als auch 2.4GHz Netzwerk vorhanden ist, verbindet sich der Mac standardmäßig mit dem 2.4GHz Netz. Das kann man ihm austreiben, indem man in den Netzwerkeinstellungen die Liste der bevorzugten Netze anpasst. Das 2.4GHz Netz hab ich ganz entfernen müssen, damit er sich zuverlässig mit dem 5GHz Netz verbindet
- die Entfernung und Position von Endgerät und Router zueinander hat – wie bei WLAN üblich – starke Auswirkungen auf die Verbindungsqualität. Bei 5GHz soll dieser Effekt noch stärker ausgeprägt sein. Glücklicherweise hat das Airport Dienstprogramm unter “Erweitert > Drahtlose Clients” eine grafische Anzeige für den zeitlichen Verlauf der Signalqualität. So kann man mit Notebook ausgerüstet den Wünschelrutengänger durch die Wohnung machen ;-)
Fazit: 5GHz mit 802.11n kann wesentlich schneller sein, es zuverlässig konfiguriert zu bekommen grenzt allerdings noch an Voodoo. Die Firmware des neuesten Airport Extreme Base Station scheint auch noch fehlerhaft zu sein. YMMV. Vielleicht schafft eine längere Beschäftigung mit den Support-Seiten für AirPort Klarheit! Im Zweifel bei den Default-Einstellungen bleiben und ein Firmware-Update für die Base Station abwarten.
Hier noch zwei Tipps zur Verwendung einer Festplatte an der Base Station:
- eine an die Station angeschlossene Festplatte kann inzwischen problemlos für TimeMachine Backups verwendet werden.
- die Festplatte kann man beim Start des Rechners automatisch mounten.
published 4 months ago (26.12.2009 16:30)
Just read: Confessions of an Economic Hit Man
There are many quote-worthy passages in this quick but insight-heavy read. Here’s the closing one:
“Whether terrorism occurs in Manhattan, Madrid, [...] it is essential that we understand that in the long-term these horrible acts will not be stopped by the military or by security guards in airports and along our borders. They will only be stopped when enough of us demand that our corporations, banks, and governments cease to exploit the majority of the world’s population and resources, and when we insist on dealing with the world from a place of compassion [...]”
Living a beautiful, secure and rich life, I guess you don’t like to hear that. I certainly don’t, but I think he is right. He just makes a damn convincing point, having played a major role in establishing that exploitive system for decades.
Watch these 20 minutes, and learn a lot. For further info, you may want to read about companies like Bechtel, Halliburton, and the United Fruit Company on wikipedia.
Link: 
published 4 months ago (04.12.2009 15:56)
Überfischte Arten, und was man noch essen kann
ESSEN
- Karpfen
- Pangasius (Bio)
- Forelle
NICHT ESSEN
- Pangasius (nicht Bio)
- Rotbarsch
- Scholle
- Seeteufel
- Alaska-Seelachs
KOMMT DRAUF AN, WOHER
- Kabeljau
- Heilbutt
- Dorade
mehr infos
- In der SZ
- bei Greenpeace
- bei in der Seafood Watch Suchmaschine des Monterey Bay Aquariums.
published 5 months ago (07.11.2009 11:18)
400 XING contacts - time for housekeeping
I just added my 400th contact on XING. If you had told me this 3,5 years ago, I’d have called you crazy and explained how I detest this “superficial networking” stuff! I used email to stay in contact with my closer friends online. And I continue to do
so today.
But my attitude towards “networking” has changed, for many reasons. I’ve become a more open person in general, I’ve seen the inside of a social networking company (it isn’t all evil, on the contrary!), I understood networking isn’t about arbitrarily adding people to a list, and I add only people I have met in person as a contact.
Still, 400 people is way more than any person can have real relations with. Theory agrees: according to Dunbar, ~150 is the cognitive limit for the number of people you can maintain stable social relationships with. So XING generally is a way to stay in touch with people I have met, and find interesting. Some of these are closer, but some of them I don’t have a “dunbaresque” stable social relationship with.
After some time you realize you’re not in touch with some contacts anymore. Someone you met at a conference three years ago. Someone who doesn’t use XING actively. Someone you had added out of politeness. Someone you invited, but now doesn’t use XING. Someone you haven’t developed a personal relation with since meeting them. Time puts everything in relation. It’s time for housekeeping! Reviewing who you consider part of your network, and who not. XING could make this much easier. This would add pure user value—save me time now when cleaning up the list, save me time in the future by having less, but the right people
to handle.
Some XING features that would make my network more transparent
- show me my contacts sorted by the number of interactions I have had with them. Interactions measured by profile visits forth and back, emails forth and back, group discussion threads we both participated in, and so on. This “interaction strength” is a metric that would be useful in many areas of the platform.
- show me a list of all my contacts by the date I added them. Let me group by month or year. This is my XING networking history. Along with the picture, I would see the comment and tags I assigned at the time.
- allow much faster and powerful tagging. This could be done with an interface similar to the “invite contacts to event” feature: AJAX-search one or more contacts, then drag and drop to a tag. Some experimentation and testing would be required to get the interface right, but the current one can be improved a lot.
- de-clutter and improve the contacts start page. Among many other things, lots of whitespace in the wrong place, and those 5 fat action icons really aren’t the most important feature.
- auto-suggest inactive people, whom I should “ping” again to have them use the platform, or remove from my contacts.
These would be powerful features for any social network, and they can be built technically. So go ahead and make XING the best social networking tool out there, and everything else will follow.
P.S.: I found the “business card” view (and a 24” monitor) to be helpful for the housekeeping process – down to 392 contacts :-)
published 6 months ago (31.10.2009 20:39)
NoSQL Berlin Meetup Notes
“The world is diverse. Act accordingly.”
—Prof. Dr. Stefan Edlich, in his talk on object databases.
Where do you store your data? In a relational database, of course. It’s so convenient to use the persistence store we are used to, which has been there for us since the day we started programming. But in the spirit of using the right tool for the job – and making our lives easier – it pays off to know other persistent storages—those which aren’t based on the RDBMS/SQL paradigma. They promise to be better suited for some of the problems we face day to day; mapping the real world to a persistent storage, scaling, and reliability being among them.
The NoSQL meetup in Berlin gave a great overview of this active and growing scene, and shed some light on the characteristics of the main tools. Here are some rough notes from the meetup. For the full monty, all video and slides of the talks are available at the NoSQL Berlin website. Thanks guys for the perfect organization!
Consistency in Key-Value Stores (Monika Moser)
The only talk which wasn’t about a specific database. It gave an introduction into the problems and solutions that we face when working with many database servers (nodes). Since the written data has to be distributed across many physical machines, there will be a noticable delay until every node has received the updated data—the replication lag. Only after the replication lag, all nodes will contain the same (=consistent) data.
Two types of consistency were distinguished: Strong consistency (updated data is immediately available to all processes in the system) and eventual consistency (at some point in time all processes will get the update).
Strong consistency is usually expensive to implement on larger systems and isn’t always necessary, so eventual consistency is often acceptable. Depending on the use case, one can go for one of these subtypes of eventual consistency:
- “read your writes” consistency
The process that wrote the data will always get the latest data. Other processes may still get old data for some time.
- session consistency
A special case of the above: only the session that wrote the data is guaranteed to get the latest data immediately.
- monotonic read consistency
after one process has read the new data, all following reads get it. So once the new data is in the system, the old data doesn’t appear again.
Monika went on to describe the CAP theorem (choose 2 of 3 for your storage setup: partition tolerance, availability, consistency), the reasons strong consistency is expensive, and the Paxos algorithm (good trade off between fault tolerance and consistency). See the slides and video for details!
My personal summary of the talk: good overview with lots of pointers to further info. And I’ll care about the details I didn’t grasp when I first need them.
Redis, Fast and Furious (Mathias Meyer)
Redis is awesome, I heard someone say.
Oh … Redis is also like memcached, but with extra features: persistence, additional commands (increment values, sets, push/pop, sorting, a text-based simple protocol). It is also slower than memcache, but not so much you would care.
It is also like K.I.T.T., if you believe Mathias.
According to Mathias, Redis is put to good use when storing statistical data (as long as it fits in memory!) and implementing worker queues.
Peer-to-peer Applications with CouchDB (Jan Lehnardt)
- Jan contradicted himself on the first slide. It read: “Relax.”. Then he started a 10_000 WPM (words per minute) presentation, that still managed to raise my interest in CouchDB again. The presentation was about the “what can it do” instead of “how to do it”. Good choice to go this way.
- a nice explanation “CouchDB is built “of the Web””—REST, JSON and HTTP are core technologies of the database.
- Learning curve: store full documents, not relations (JSON). No data normalization into tables => make developers happy, not computers.
- meant to be robust: append-only design for the database file. on crash, old data is not damaged.
- scales out (horizontally). Does Master-Master replication. No scaling built in, but prepared (use couchdb-lounge). Then a scaled CouchDB cluster looks like a single DB from the outside.
- scales down (runs on small devices). Own your own data, take it with you on your device.
- incremental map-reduce: after updates, only the affected documents get reindexed
- as with any document-oriented database, store full documents as JSON, not relations. Good tip in the Q&A: a document is something that will be updated and used as a whole. “put stuff into seperate documents when it is updated seperately”. There’s no clear guideline however, it depends on the use case.
- RESTful HTTP: “text-based protocol is not slower than binary” / “all HTTP infrastructure and tools can be used”
- BBC uses CouchDB in production, after a survey/comparison of storage solutions.
- free online book by O’Reilly: CouchDB, the definitive guide
Riak (Martin Scholl)
- document-oriented DB like CouchDB. “Riak combines a decentralized key-value store, a flexible map/reduce engine, and a friendly HTTP/JSON query interface to provide a database ideally suited for Web applications.”
- 100% awesome. Though disputable, even more awesome than CouchDB.
- the Riak “Data-Sphere” consists of: Bucket x Key x Document
- GET/POST/PUT /jiak/<bucket>/<key>
- travel the graph/links between documents with map/reduce
- but: travelling links is expensive (no caching of map/reduce result, although possible to implement it yourself)
- Bucket: can have as many keys as you want
- chainable map/reduce stages—unique feature of RIAK
- “It is extensible and configurable in many ways. Riak is a perfect fit for buiding reliable and scalable custom data storage systems.”
- unfortunately my brain went offline through the second half of the talk … See the video
MongoDB (Mathias Stearn)
Quote: “I won’t tell you MongoDB is awesome. But I hope you’ll know it is after my talk.”
- Mongo as in “HuMONGOus” scaling
- Schemaless; data organized into Databases and Collections (like tables). But document-oriented (not a K/V store)
- Good when you don’t know up front what you will be looking for (example: logfile analysis), and want to store everything.
- extended JSON with data types Date, Int32/64, OID, Binary and called it BSON. B as in binary.
- Wants to integrate with native language as well as possible. I.e. “db.users.find({$where: “this.a + this.b >= 42”})” instead of “RestClient.get ‘http://example.com/resource’”. And, btw. old-school C++.
- changing only part of a document is possible. features: $set, $inc, $push, $pull, $remove for subdocuments
- “you can put all data in one place, MongoDB”. Get rid of RDBMS.
- works for 1 billion documents.
- map/reduce + finalizers.
- uses the eventual consistency model (see first talk)
- uses MMAP database files (OS kernel) to automatically use available RAM
- async modifications: no server response, client doesn’t wait. good for bulk inserts.
- good for: websites, complex objects, high and low volume sites, real-time analysis.
- bad for: complex transactions, business intelligence
4th Generation Object Databases (Stefan Edlich)
- these have been around for 15 years
- “no impedance mismatch”. These DBs are very nice to work with OOP—no disassembling objects into tables required, and back. Just dump full objects, and load them again.
- but: when refactoring code, DB has to change. No insulation between code and data.
- looks as if they are alive and well in a specific niche (extremely large datasets)
- db4o is a simple way to try a OO database.
- typical applications: transportation networks, tree structures, social graphs, object traversal, capture space (grok this!). He gave an example of one OOD application which stores 3.2 Mio. objects per second, 1TB of data per hour.
- no convincing answer why OO databases haven’t entered mainstream, while OO programming has—it sounds like such a good idea. My impression was they are a great tool for specific uses (high performance, huge scale), but exotic and commercial solutions with high up-front investment.
- Somehow I wonder if document-oriented databases will make it, when object-oriented DBs haven’t …
A talk not held: Neo4j – The Benefits of Graph Databases
There was no talk on GraphDBs, which are designed to store nodes and the relationships between them. As in social networks (nodes = people, relationships = connections/friendships). Slideshare to the rescue, it has Neo4j – The Benefits of Graph Databases. There also was a talk on Neo4j at NoSQLEast.
published 9 months ago (02.08.2009 11:45)
Top Talks of Rails Underground
According to SpeakerRate. 5 is the maximum rating.
rated > 4.5
- Dead simple JavaScript Unit Tests in Rails with Blue Ridge and Screw.Unit, Dr. Nic Williams 4.52
- Agile Happiness, Paul Campell 4.52
rated > 4
- Grand Unified Theory of Software, Jim Weirich 4.36
- Refactoring With Fire, Gwyn Morfey 4.26
- Rails and the internet of things, Elise Huard 4.13
- And the Greatest of These Is … Rack Support, Ben Scofield 4.12
- Keynote – Interfaces and the future of Ruby, Yehuda Katz 4.10
- Blood, Sweat, and Rails, Obie Fernandez 4.09
- Working outside-in with Cucumber, Joseph Wilk 4.08
rated > 3.5
- Rails i18n From the Trenches 3.99
- Plenary: JRuby & Rails 3.98
- Sphinx: Beyond the Basics 3.96
- Sneaking Ruby & Rails Into Big Companies 3.95
- Invoicing Gem – Sales & Payments In Your App 3.95
- CouchDB and Ruby 3.90
- From the Keyboard to the Community 3.90
- Distributed and Concurrent Programming using RabbitMQ and EventMachine 3.84
- Agile Deployment with Ruby 3.84
- Mobilize Your Rails Application 3.83
- Launching Ruby on Rails projects: A checklist 3.77
- Bringing the Web to Your Desktop with MacRuby 3.57
rated > 3
- Rails Is a Hammer 3.33
- Panel Q&A 3.29
- Working with Legacy Rails Apps – Technical Debt Hell and how to work your way out of it 3.28
- Git Basics 3.20
- Behaviour driven monitoring with cucumber-nagios (no ratings)
published 9 months ago (26.07.2009 19:38)
London and Rails Underground recap
Update: added links to conference-related stuff at the bottom of this post.
Some notes, roughly chronological, left in draft state.
- Rails developers usually don’t seperate data access layer and domain model.
- This can constrain how easily the domain model can be changed. If done, saving/loading and validating data is on the DAOs, and “the interesting stuff” (business logic) lives in the model objects.
- Q: how do you develop a domain model? A: may should be explained in Analysis Patterns
- SASS and lesscss are nice extensions to css. They require processing the CSS, however.
- at least three German-speaking universities now have courses where they use Rails (Bremen, Potsdam, Salzburg).
- Refactor vs. Rewrite. First, “find out the hard core of what the client actually needs”. Be brave and delete, change.
- clients of “rescue mission” projects didn’t get what they wanted from their last dev shop. The time and money reserved for the project are usually already spent, so they are in a hurry. => as a dev team, you need to show progress as early as possible.
- do the agile thing as well—prioritize by business need
- Don’t change code that you don’t like but which works well. Overcome your own prejudice and deal with the client’s money responsibly. Part of being professional, imho. Resist the Not invented here syndrome. Especially if the code is well tested. You can always refactor it when continue to work in that area.
- don’t dive into removing complexity as a first refactoring step. Look for easy targets first.
- Watch team morale on legacy code projects. Always pair.
- Read the Refactoring book before starting, and really apply the techniques step by step when doing non-trivial stuff. Always keep the application running while changing structure.
- When coding normal apps, refactor as you go, don’t see it as a separate activity, don’t speciallly reserve time for it.
- always manage your client’s expectations. Underpromise, overdeliver.
- JRuby has the by far best compatibility of the alternative Ruby implementations. It has an extensive test suite.
- It allows you to change between 1.8 and 1.9 with a command-line switch.
- ActiveRecord via JDBC is slow.
- JRuby is the only Ruby implementation with real native threads.
- Rack allows inserting code before and after the application handles a request. And allows plugging together different frameworks and components, and access session data from one in the other via Rack::Session. “Middleware” examples: Rack::Profiler, Rack::MailExceptions, Rack::Cache.
- Rails 3 release: “could roll it up and ship” any time. Rails development has always been like that. There’s never a “Todo” list of what will go into a release.
- They will do so when they feel they have done enough. But at least one thing Yehuda would like to do is get ActionMailer on the rewritten ActionController code.
- London’s monthly Rails usergroup meetings easily exceed 100 people.
- to introduce new technologies in places reluctant to change, first do ugly or boring stuff no one wants to do anyhow. With Ruby that could be: automate manual processes, write a test tool, small internal applications, quickly build prototypes, wire together systems. Realize that Ruby is perfect for glue code. Introduce the techniques (agile), not only the technologies.
- A couple of experienced people fear that the new JVM Scripting languages (Clojure, Scala, ...) may stop the stream from Java-resignees to Ruby.
- CouchFoo is intended to allow smooth ActiveRecord/RDBMS => CouchDB migration. This is a good first step to get on the couch. Then you can start wrapping your head around how to persist stuff with document-oriented databases, which I find the hardest part. “Performance tuning” of CouchDB is a whole new topic to be discovered.
- With couchDB, the cost of index updates is incurred at read, not at write as with RDBMS. Index updates at read can be suppressed with :update => false. Read CouchFoo::Base for performance info.
- #bulk_save for performance.
- a good use for document-oriented DBs is when the data structure changes often and future “schema” development is unpredictable.
- CouchFoo generates views for simple AR-style finders on the fly. Nice!
- Dr Nic once more proved to be the best Rails entertainer (_why is in his own league, of course, but wasn’t present to present).
- the i18n gem has great new features in 0.2.0 and edge: pluggable extensions, translation procs, advanced pluralization rules (implemented with procs), translation fallbacks, backend fallbacks, etc. Using it in current Rails currently requires a hack, however. See the Unicode CLDR Project for a massive amount of localization information.
- Globalize 1 happily overused metaprogramming, had to hack into Rails big-time, and as such is a PITA to migrate to the new Rails i18n. Any solutions?
- Kasabian kick Oasis’ ass on stage (according to London press).
- Rough trade in Brick Lane reminds you what’s cool about a real-world record store.
- LBI has 400 employees, a large terrace where you can work, and friendly people doing lots of barbecues.
- ExtJS is a useful rich client library with nice client-server data transportation, interface elements and data binding. It doesn’t have to look like Windows. It lacks a high-level architecture, though. It’s not free for commercial work (150 per developer), only for open source.
- Food in London is better than expected; even the traditional (Lamb stew, Apple Crumble & custard). Girls are cuter than expected, as well.
- London weather follows the same patterns as in Hamburg. Quick rains, lots of grey skies, sometimes sun. A bit warmer.
- Kevin Davy played the trumpet for Lamb, on tracks like Merge. Today he has fun playing around with electronic effects at his Jazz gigs.
- ””Now wash your hands””:http://www.flickr.com/photos/phil76/3759350196/in/set-72157621719325175/ was a design agency that built cool stuff in their time. Today only toilets in Indian restaurants remind of their glory.
- Hashrocket has guest pairs regulary. You can visit them at Jacksonville, Florida, stay at their guest house, and pair with them on the regular work.
- London is green, can be sunny and beautiful.
- a taxi from Russell square to Denmark Hill costs less than 20 pounds. Good if you’ve already spent the same amount on beer.
- the mapping of the British pound shapes and sizes to their value is only obvious to the British themselves. They lovingly call the coins shrapnel.
- Conaissence can be seen as underlying principle of many OOP design rules. And it’s a word that only Jim Weirich uses, so far.
- Paul Campell is the best storyteller of the Rails world.
- sheepexchange.com is a new agile venture from Ireland you should be following.
- http://delicious.com/tag/html-livewire is a website development framework project that allows annotating changes in the page itself.
- the Rails community is as great as ever.
- Smaller conferences are better.
For a more throrough summary of the talks, continue reading at rubypond: day 1, day 2.
Links:
- rate the talks at speakerrate.com
- view my flickr set of the conference and London trip
- view everyone’s photos of the conference
- read the twitter stream for #railsunder