Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives

Put Your System on a Diet: Replace Bloated Apps with Command-Line AlternativesModern operating systems have no shortage of feature-rich applications. The problem: Sometimes feature-rich turns into flat-out bloat. From email to music to Twitter and beyond, put your system on a serious diet with these command line alternatives.

Command Line Applications for Almost Any Task

You may have thought that that the command line was only useful for manipulating files and directories or executing obscure commands that were better left to wise Linux beards. We won't argue with you (obscure commands wielded by wise Linux beards are awesome), but we do want to point out that you can run all kinds of robust, feature-rich applications from the command line. Even better-they're extremely lightweight and capable replacements for desktop counterparts. Here's a look at some of the best command-line apps out there.

Note: For the purposes of this post, we're assuming you're using a terminal running the Bash shell on Linux or Mac OS X, and if you're on Windows, we're assuming that you're running the powerful Cygwin command line tool rather than the anemic Windows command prompt. The majority of these examples should work on any platform, though some of the utilities might require extra steps to install under Cygwin. For more on Cygwin, see parts one, two, and three of our series on using Bash under Cygwin (the tips apply to Linux and OS X as well).

Read Email with Mutt

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives
You can use the powerful mutt email client to check your Gmail account, or any email account if you choose. It'll take a bit of work to get it setup and running, but once you have done so, you'll have a fast command-line email client with shortcuts very similar to Gmail itself.

Listen to Music with cmus

cmus.jpg


You can listen to music through your terminal shell with a command-line application called cmus, which lets you easily browse through and play your music, and there's even a few patches that will send your current song to Last.fm. Hat tip to One Thing Well.

If you're a Mac user, you can also create a script that will let you play your music without having to select a particular song, or even know the full name—you can just type a command like fplay muse to play every Muse song in your collection.

Get Your Tweeting on with TTYtter

While the terminal is generally a powerful way to get things done, you can also use it to waste loads of time if you want. While you'll read many tutorials that tell you about using the curl command to connect to Twitter, they are shutting off basic authentication in a couple of days, so you can't use that method anymore.

Never fear, you can continue to waste time on Twitter by using the ttytter command-line twitter client, which has full-featured support for reading, replying, searching—and it supports OAuth.

Take IM to the Terminal with Finch

You can use the command-line Finch client to connect to any number of instant messenger protocols, and since it works off the same configuration file as Pidgin, you could use all your accounts from either the GUI or the shell.

Manage Your To-Do List with todo.sh

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives
You can create and use your own to-do list from the command line using Gina's own Todo.txt CLI utility, which has support for easily entering tasks, including projects, colors for priorities, and a lot more (there's even an add-on to push or pull to Remember the Milk). For basic usage, check out our guide on managing your tasks from the command line.

irssi Brings IRC to the Terminal

There's loads of command-line IRC clients, but if you're looking for one that's powerful, flexible, and fairly easy to use, check out irssi. You can install it through most repositories.

Browse the Web with Lynx

You can easily browse the web using the command-line Lynx web browser, and while it's not really suitable for any kind of serious browsing when you want more than plain text, you can combine it with bash aliases to let you do quick Wikipedia lookups or browsing simple sites—the mobile versions of some web sites work fairly well in Lynx. Lynx is still included in many Linux distributions out of the box, but you can also download a version for OS X or Windows (with Cygwin).

Manage Google Calendar with gcacli

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives


You can view your agenda or even add events directly to Google Calendar using the gcalcli utility, which supports listing calendars, showing the agenda, displaying the calendar in a graphical display, searching, or even using as a reminder service. If you simply want to add events to Google Calendar using natural language syntax or grab your daily schedule with less fancy formatting, you can check out our guide to using GoogleCL instead.

Write and Edit Google Documents with GoogleCL

You can edit Google Docs documents in vim from the command line using the GoogleCL utility, which interfaces with Google Docs using the API and allows you to easily edit documents, or create new ones.

Take Quick Notes

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives

If you don't need a full-blown document repository and just want a place to store simple notes, you can turn your command line into a fast note-taking tool with a simple script that lets you store notes by name.

Control Another Windows PC Using Dropbox and Akira

You can use a combination of the Akira command-line application and Dropbox to remotely control one Windows PC from another one, allowing you to grab screenshots, run applications, kill processes, or perform any number of other tasks.

Use bc as a Command-Line Calculator

While you can setup an alias that turns awk into a command-line calculator, your best bet is to simply use the bc command to perform just about any calculation. If you don't want to use interactive mode, you can use a command like this to put it all on a single line:

echo "2 ^ 3" | bc

Batch-Convert Images with ImageMagick

Whether you want to convert a whole bunch of images from one format to another, resize them, or create a set of thumbnails, the command-line ImageMagick tools are your best bet. You can even use these extremely powerful commands to draw new images or add text on top of an existing image. For instance, to convert an image from PNG to JPG and resize it to half size, you'd use a command like this:

convert file.png –resize 50% file.jpg

Use the Terminal as a Stopwatch

You can use a simple command from the shell as a stopwatch if you need to see how long it takes to do something—just type the following command into your terminal, and then hit Ctrl+C when the time is up.

time cat

Create a Simple Ad-hoc Web Server to Share Files

You can quickly share files from one machine to another with the built-in web server included in your Python distribution (assuming you have Python installed). Just start this command from any folder, which will start a simple web server—you could then use the wget command (or, you know, use your web browser if you must) to grab a file off this directory from a second computer.

python -m SimpleHTTPServer

Search Wikipedia with a Command-Line Trick

You can use the dig command from the terminal to perform quick lookups on Wikipedia for definitions. For instance, to see the short description for Futurama, you could use the following command:

dig +short txt futurama.wp.dg.cx

Watch Star Wars

Put Your System on a Diet: Replace Bloated Apps with Command-Line Alternatives Who needs fancy CG? You can have some fun watching an ASCII version of Star Wars in your terminal with this simple command:

telnet towel.blinkenlights.nl

These examples not enough for you? Check out our top 10 command-line tools, our list of useful commands for Mac users, our guide to turbocharging your terminal, or the list of ten handy bash aliases.

What are some of your favorite command-line tricks? Share your advice with your fellow readers in the comments.

The How-To Geek spends 47% of his time at a bash prompt. His geeky articles can be found daily here on Lifehacker, How-To Geek, and Twitter.

Send an email to How-To Geek, the author of this post, at lowell@lifehacker.com.

track'); track


Your version of Internet Explorer is not supported. Please upgrade to the most recent version in order to view comments.

GUIs brought personal computing to the mainstream. Command lines have always been for the computing above and beyond types. With today's hardware making their previous iterations obsolete within a matter of months, I doubt a little "GUI bloat" will be that great of a cost in favor of speed and performance. Reply


Cygwin: Bringing Dependency Hell to Windows since 1995! Reply


I like my bloated, pretty apps. Reply


don't forget playing nethack and dopewars in the terminal. fun times.... Reply
silvermoonstar3 promoted this comment

If people wanted command-line apps, why were Windows and OSX developed? Reply
silvermoonstar3 promoted this comment

Edit text/code with vim if you're willing to learn. Reply


Download torrents with rtorrent. Reply
jonny6pak promoted this comment

Some more comments... : On a New Road

Some more comments...

Tuesday August 24, 2010

I apologize for taking so long to reply to any of the comments on my previous blog entry. Here are answers to a few...

All that I can say is: Salute Sun, Salute. You were a noble in time of bastards. Sun, you are badly missed...
We tried. DIdn't always succeed. One of the sad things about modern commerce is that being a bastard is a good thing. At least in Wall Street's eyes.
James, can you expand on why Android's fragmentation limits programmers' freedom? I'm an Android developer and I really don't see this at all. The code I write works without any changes on most Android handsets and it's certainly orders of magnitude than Java ME ever was
Java ME's fragmentation was far worse than we would have liked. Some of it was politics in the early days, then 10 years later, small cracks in interoperability become gaping holes. A big factor was that the incredible constraints of the handsets 10 years ago made consistency almost impossible. Today's high end phones have an incredible amount of RAM and CPU, which makes interoperability hugely easier for Android.

Fragmentation limits programmers freedom because it increases the amount of work that a developer has to do to address a large market, and the larger the market you can address, the better your chances are of being financially viable. So long as handset makers are "lazy" about implementing Android and don't take advantage of the freedom they have to alter the Android source code much, life for developers can be good. But differences will creep in as the Android world ages: version skews, different bug fixes, and the handset makers attraction to "added value" and "product differentiation" will all take their toll without strict governance.

Hey James. Your discourse presents a well reasoned argument for the issues of software development in the 21st century and how we get product to the mainstream. Thanks for your firestorm. The evidence of fragmentation of Android is here: Vodafone UK users of went apocalyptic when they thought that they upgrading HTC Heros to Android 2.1 only to receive branded applications. Vodafone eventually backed down. This was a carrier not a phone manufacturer. The battle of the future is a walled garden vs freedom 2 modify your device. Correct.
Absolutely. It will only get worse. The "walled garden" is the mostly deadly idea ever. All of the phone companies are addicted to it, even though I've had (for example) the CTO of a very large carrier admit in private that the whole walled garden concept was a disaster. They just can't stop themselves. They've got piles of bogus reasons. For example: The first cell phone app store was the one built by NTT DoCoMo a decade ago. It was structured almost identically to Apple's - easy to become a developer, easy deployment, 70% of revenue to the developer - it's pretty likely that Apple got a lot of ideas from there. DoCoMo made buckets of money and there was a huge amount of activity in the Japanese cellphone developer market. Developers were going from napkin sketch to millionaire in a few months. It was huge. But what did the phone carriers around the world think of this? The average attitude was "Those fools at DoCoMo! They left all that money on the table! Why did they make life so easy for developers? We'll just keep all that money to ourselves". So they created walled gardens. I actually had one senior executive at a carrier say (approximately) "We've had a crack team of our analysts evaluate what applications our customers need on their cell phones. There are a dozen of them, which we'll have our developers build". Idiots.
Apple gave you shared libraries in Java.
That was then, this is now. In the early days, Apple had a great Java team. They did lots of good work. But when they got successful enough that they didn't need outside developers, they built their own walled garden.
I was at Sun back in 1987-88. They seem to have started thinking about patents a bit in 88.
Yes. There was some patenting activity early on, but not a lot. It really got crazy after the RISC patent case.
Mind your business. Mr. Gosling is old enough to defend himself. Nothing in his post is correct about Apple. For example. Apple has the right to create a platform and not invite Mr. Gosling's love child. Nor let Google in to sell its ads in the iphone. I don't see Google allowing anyone in the google.com ad business. So why should Apple allow it. especially when important customer information is being stolen by google. Since When is Apple's ad network a threat to mankind when it is only going to live in the iPhone. You mean that is a direct threat to Google.
They totally have the right to create their own platform. They totally have the right to create their own ad network in competition to Google. But I also have the right to be grumpy about the tools they require for software developers. Steve is well on his way to becoming the dictator he lampooned in the 1984 commercial. And yes, I meant that Apple's ad network threatens Google. They only really turn into threats if they achieve monopoly-level success and then abuse that monopoly.
In Oracle's hands, Java is doomed. I have to agree that Mono has a much brighter future than Java since last week. I love Java, but can't say the same about Oracle! It's unfortunate that MySQL and VirtualBox will share fate with Java - just like OpenSolaris
In my brief time getting to know Oracle, they made it very clear that you're mostly right (I'd quibble with the Mono part - it's still silly). The key phrase is "in Oracle's hands". It doesn't have to be that way. Lightning might strike and they might live up to their 2007 commitment to create an independent Java foundation. I'm not holding my breath, but if enough customers rose up in revolt, it could actually happen. But it would require Oracle customers to do this, since the only thing that Oracle pays attention to is money, and that's what customers hand over to Oracle.
thank you for telling us this and we able to see from different prospective. But we all hope, an agreement can be come out from oracle,google side to address this revenue issue. if this can be solved, surely java will continue to prosperous. Or if we prefer continue like thist. you sue me, i sue them. this will be endless profit for lawyers
No matter what the merits of the case may be, or who is right, or who has a "right" to do what, the crossfire in the battle will be hugely distractive (and I don't just mean the patent case). I wish they'd all vent their testosterone elsewhere.
The underlying problem here is that the rules of the current economic game favor evil (mostly in the form of cancerous growth). The degree of corporate liability for the evil is actually limited. Exxon has bought far more laws than Google has--so far. Whatever you think about Microsoft's software (and I think it reeks like the big dog's m0e), their economic model apparently works. For OSS, I think one answer is better economic models. One idea might be a kind of shared charity reverse auction pseudo-stock market. Ergo: http://eco-epistemology.blogspot.com/2009/11/economics-of-small-donors-revers... There's a lot of confusing because "free" is so badly overloaded in English. The important sense of free involves meaningful, significant, and unconstrained choice. Anti-trust is NOT a penalty for success. However, improved laws should insist that overly successful companies reproduce--by dividing and competing against themselves.
It's not so much that the game favors evil, but that the definition of "good" is really twisted:
 Good adj: anything which increases the stock price.
Considerations about employees, products, customers and community are all secondary. They only enter the equation as ways to achieve goal 1. Morality or high principles have no place in the corporate discourse. They maximize the stock price, within the bounds of the law. Corporations like Oracle and Exxon tend to be perfectly rational. They "buy laws" because it's perfectly legal to spend money on lobbyists and political campaigns. While you and I might think that it is morally reprehensible to buy elections, like the recent case with Target, it is nonetheless totally legal. Given the rules of the game, it would be bad for a corporation to not buy an election, if failing to do so would negatively impact their stock price. I could rant for a long time on this one, but not today… The whole modern concept of a public company is deeply flawed. But the game is what it is.
I'd be interested in hearing answers to the issues no posted. What happened to the Lighthouse desktop apps? Why did their conversion to Java fail?

As a former Sun guy myself, I too am disappointed that more didn't come of the Lighthouse acquisition. However, you do have to remember the context. It was just after the mid 90s and there was an opportunity to enter/win the server side app development approach. Sun was better positioned to do that and it was probably much more lucrative than building out Java desktop applications. I think Sun made the right decision and got a lot of mileage for SUNW on Solaris/servers/JavaEE. More so than building a better mail client or presentation tool for sure.

The conversion didn't fail: it was never attempted. There were lots of reasons: Microsoft and three giant lawsuits over the late 90s/early 00s chilled desktop work; development funding was restricted; and enterprise software was hugely more profitable and didn't involve collisions with Microsoft's monopolies.
I think it's quite hard to stop fragmentation on mobile without stopping innovation. Mobile phones differ radically in speed, screen, memory, bandwidth, input-method, and so on, to produce a single app that runs everywhere well is a tall order, even if the APIs were identical. J2ME was a nice try, but the profiles themselves created fragmentation. Android devices are fragmented in a smaller way by contrast, first, the bar for performance minimum and OS features are set way higher. Secondly, there's no profiles
This was very true in the mobile world a decade ago and was a huge driver of fragmentation; but with todays dramatically more powerful handsets, and especially given the concentration on high-end handsets, there's no reason for any fragmentation.
Hello, With all respect I beg to disagree with James(Thanks for Java BTW) here. Java was developed by SUN but only succeeded because of the promise of openness. Remember it was an itch for many people at the time( both from SUN and out of SUN) to use a cross platform language without restrictions. Everybody including Google, IBM, BEA, and ... Oracle bought into Java because they believed they could do so without any restrictions. Java would have failed if it belonged to somebody. If today it is proven that it belongs to Oracle, it will Fail. I would never touch c# with a stick because I know I am being trapped. Just my 2c.
Yes and no. The vision of freedom that most of the big corporate interests had was the ability to make their platform sticky: to destroy interoperability so that (for example) Java software developed on Microsoft platforms could only run on Microsoft platforms. They wanted the freedom to capture developers. While Microsoft may be the one that got caught in a big court case with a pile of incriminating evidence in the public record, few of the other corporate actors were much better. "Freedom" is a freakishly relative word. The freedom of the large software companies is directly at odds with the freedom of developers.

Comments[3] Share 

-->

Understand FxContainer in 10 minutes

Its a fast lane world and I know it.

That’s exactly why I have created a slidedeck with 20 slides to cover the FxContainer. You can read it in 10 minutes and start using FxContainer in your JavaFX applications.

Download (PDF, 524.76KB)

You can also download it here:  JavaFX Dependency Injection with FxContainer

You can get additional (sometimes overlapping perspective from my earlier blog

http://objectsource.com/blogs/2010/08/fxcontainer-the-ioc-container-built-using-javafx-and-for-javafx-applications/ 

or my “other blog” at java.net that has more details for the detail oriented folks

http://weblogs.java.net/blog/srikanth/archive/2010/08/21/fxcontainer-ioc-container-written-javafx-javafx-applications

Happy reading

Emulatory terminala wzorowane na grze Quake dla Linuxa i MacOS X

Emulatory terminala wzorowane na grze Quake dla Linuxa i MacOS X

Opublikowano 21 sierpnia 2010 przez Franek

Niektórzy często korzystają z konsoli, wszak wiele czynności można wykonać szybciej i wygodniej w konsoli. Taki apt-get upgrade uruchamia się szybciej niż Synaptica czy Menedżera aktualizacji jeśli chcemy uaktualnić system, przykładów można mnożyć. Terminal jednak należy uruchomić, czasem on ginie w gąszczu innych otwartych okien lub na innym pulpicie wirtualnym. I tu wyśmienicie sprawiają się emulatory terminala wzorowane na tych z gier first person takich jak Quake. Uruchomione są one w tle i kiedy zachodzi potrzeba ich użycia po wduszeniu skrótu klawiaturowego wysuwają się z góry ekranu dając natychmiastowy dostęp do prompta. Oto mini przegląd dwóch takich emulatorów dla GNOME, jednego dla KDE SC oraz jednego dla MacOS X.

Tilda

Tilda to emulator terminali napisany w GTK+. Obsługuje karty, przezroczystość, zmianę koloru tła. Posiada również obsługę kart oraz animacji. Jest bardziej minimalistyczny od Guake.

Instalacja Debian/Ubuntu:
sudo apt-get install tilda

Wiki Tilda tilda.sourceforge.net

YaKuake

Oparty jest na silniku konsoli KDE oraz wyposażony w karty.Począwszy od wersji 2.8 YaKuake oferuje zmianę skórek, tryb pełnoekranowy, oraz podział okna na kilka terminali. Posiada obsługę kart oraz animacji.

Instalacja Debian/Ubuntu:
sudo apt-get install yakuake

Strona domowa YaKuake extragear.kde.org

Guake

Guake ma takie same cechy jak Yakuake i Tilda, ale próbuje łączyć najlepsze cechy w jednej aplikacji opartej na GTK. Guake został napisany od podstaw.

Instalacja Debian/Ubuntu:
sudo apt-get install guake

Strona domowa Guake quake.org

Visor

Jest przeznaczony dla komputerów Apple, ponieważ działa na systemie MacOS X, obsługuje on karty.

Instalacja ‘trochę’ trudniejsza niż odpowiedników w systemach Linux:
1. Zainstaluj SIMBL w najnowszej wersji 0.9.x
2. Przenieś Visor.bundle do katalogu ~/Library/Application Support/SIMBL/Plugins (jeśli go nie ma to utwórz)
3. Uruchom ponownie Terminal.app
4. Skonfiguruj skróty klawiszowe w Visor Status Menu >> Visor Preferences … >> hot-key

Strona domowa Visor visor.binaryage.com

Zrzuty za Wikipedią z wyjątkiem Vistor którego zrzut pochodzi z jego strony domowej

Udostępnij innym:

         Delicious

  

Musisz zobaczyc:

Tried Tilda but Guake is much better!

Quite the firestorm : On a New Road

Quite the firestorm

Sunday August 15, 2010

The last couple of days have been quite an entertaining firestorm of press and blog-o-sphere commentary. Lots of questions were brought up that give me a bottomless supply of blog topics. I hope I have the common sense to not write on most of them :-)

But there are some topics I feel I should briefly say something about:

  • In Sun's early history, we didn't think much of patents. While there's a kernel of good sense in the reasoning for patents, the system itself has gotten goofy. Sun didn't file many patents initially. But then we got sued by IBM for violating the "RISC patent" - a patent that essentially said "if you make something simpler, it'll go faster". Seemed like a blindingly obvious notion that shouldn't have been patentable, but we got sued, and lost. The penalty was huge. Nearly put us out of business. We survived, but to help protect us from future suits we went on a patenting binge. Even though we had a basic distaste for patents, the game is what it is, and patents are essential in modern corporations, if only as a defensive measure. There was even an unofficial competition to see who could get the goofiest patent through the system. My entry wasn't nearly the goofiest.
  • Sun got a lot of heat for not going full open source early on (and there's a lot of disagreement over what "full open source" would mean... GPL? Apache?). But freedom is a funny concept. It's often a function of point of view: freedom for one could restrict the freedom of another. The freedom we were most concerned about was the freedom of software developers to run their applications on whatever OS or hardware they wanted. In opposition to that, the platform providers wanted the freedom to make their platforms as sticky as possible. Microsoft was the poster child for stickiness: they signed a contract saying that they'd support interoperability. Shortly thereafter they broke that promise by making it the case that if Java programs were developed on Windows, they wouldn't run anywhere else, so we took them to court and won. We were pretty careful about enforcing interoperability on desktops and servers. As an interesting aside, that commitment to interoperability is why Apple dislikes Java. Having OS X apps run on Linux or Windows doesn't make them happy. Apple wants to add your technological distinctiveness to their own.

    When it came to cellphones and JavaME, we weren't as able and successful at achieving interoperability. There were a lot of factors, but it all added up to pain for developers and a chilling of the software market. When Google came to us with their thoughts on cellphones, one of their core principles was making the platform free to handset providers. They had very weak notions of interoperability, which, given our history, we strongly objected to. Android has pretty much played out the way that we feared: there is enough fragmentation among Android handsets to significantly restrict the freedom of software developers.

  • Money was, of course, also an issue between Sun and Google. We wanted some compensation for the large amount we would be spending on engineering. Google did have a financial model that benefited themselves (that they weren't about to share). They were partly planning on revenue from advertising, but mostly they wanted to disrupt Apple's trajectory, and Apple's expected entry into advertising. If mobile devices take over as the computing platform for consumers, then Google's advertising channel, and the heart of its revenue, gets gutted. It doesn't take much of a crystal ball to see where Apple is going, and it's not a pretty picture for Google or anyone else.
  • Don't interpret any of my comments as support for Oracle's suit. There are no guiltless parties with white hats in this little drama. This skirmish isn't much about patents or principles or programming languages. The suit is far more about ego, money and power.
  • It's a sad comment on the morality of large modern software companies that Microsoft, while I don't think they've gotten any better since Sun sued them, probably has the high ground.
It's tough living in a world of Borg-wanna-be's.

Comments[92] Share 

-->

Aloha editor - HTML5 WYSIWYG Editor

Aloha editor - HTML5 WYSIWYG Editor

The most advanced browser based Editor lets you experience a whole new way of editing. It?s faster than existing technologies and offers unprecedented functionalities. Aloha Editor is designed to be the easiest to use, the fastest in editing and the best in its functions. Its feature include:

  • No reload. No popup. No need to preview.
  • The floating menu. A brand new lightweight context menu
  • Tables for the web
  • Editing and formatting text without Markup
  • 80% loading speedup for multiple instances
  • WYSIWYG for dynamic content
  • Contenteditable. HTML5 available

http://aloha-editor.com/


     355

Please enable JavaScript to view the comments powered by Disqus. comments powered by Disqus

Related Products

FreeTextBox - HTML editor for ASP.NET

FreeTextBox is the most-used HTML editor for ASP.NET. It is compatible with IE on the PC, and Mozilla and Firefox on all platforms. It is used in major Open Source projects such as Community Server and DotNetNuke as well as excellent packages like Smarter Mail.

Read more

CKEditor

CKEditor is a text editor to be used inside web pages. It's a WYSIWYG editor, which means that the text being edited on it looks as similar as possible to the results users have when publishing it. It brings to the web common editing features found on desktop editing applications like Microsoft Word and OpenOffice. It's an editor to be used inside web pages.

Read more

TinyMCE

TinyMCE is a platform independent web based Javascript HTML WYSIWYG editor control. It has the ability to convert HTML TEXTAREA fields or other HTML elements to editor instances. TinyMCE is very easy to integrate.

Read more

Xinha

Xinha (pronounced like Xena, the Warrior Princess) is a powerful WYSIWYG HTML editor component that works in all current browsers. Its configurabilty and extensibility make it easy to build just the right editor for multiple purposes, from a restricted mini-editor for one database field to a full-fledged website editor. Its makes it an ideal candidate for integration into any kind of project.

Read more

NiceEdit

NicEdit is a Lightweight, Cross Platform, Inline Content Editor to allow easy editing of web site content on the fly in the browser. NicEdit Javascript integrates into any site in seconds to make any element/div editable or convert standard textareas to rich text editing.

Read more

Wymeditor

WYMeditor is a web-based WYSIWYM (What You See Is What You Mean) XHTML editor (not WYSIWYG). WYMeditor has been created to generate perfectly structured XHTML strict code, to conform to the W3C XHTML specifications and to facilitate further processing by modern applications.

Read more

phpMyFAQ

phpMyFAQ is a multilingual, completely database-driven FAQ-system. It supports various databases to store all data, PHP 5.2 (or higher) is needed in order to access this data. phpMyFAQ also offers a multi-language Content Management-System with a WYSIWYG editor and an Image Manager.

Read more

OpenCMS

OpenCms from Alkacon Software is a professional, easy to use website content management system. OpenCms helps content managers worldwide to create and maintain beautiful websites fast and efficiently. OpenCms is based on Java and XML technology.

Read more

dotCMS

dotCMS is one of the fastest growing open source enterprise content management systems in the world. Twice recognized by Packt Publishing, and downloaded by tens of thousands of people, dotCMS is the choice for enterprise web CMS.

Read more

Strelin CMS - A Joomla fork

Strelin is a fork of the great Joomla! 1.5 content management system. Joomla! 1.5 is so widely used content management system. As Joomla! is moving towards 1.6 with big core changes, Strelin has been started for those who want new features but don't want to get into possible extra migration work.

Read more

devBlogi: Absolutne minimum, które każdy programista powinien koniecznie, absolutnie wiedzieć na temat Unikodu i zestawów znaków (bez wymówek!)

Oryginalny post: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Autor: Joel Spolsky

Czy kiedykolwiek zastanawiałeś się nad tajemniczym tagiem Content-Type? No wiesz, tym, który powinieneś umieścić w HTML-u i nigdy do końca nie wiesz, co powinien zawierać?

Czy kiedykolwiek dostałeś mejla od przyjaciół z Bułgarii z tematem "???? ?????? ??? ????"?

ibm Byłem przerażony, kiedy odkryłem, jak wielu programistów nie jest na bieżąco z tajemniczym światem zestawów znaków, kodowań, Unikodu, całego tego zamieszania. Kilka lat temu beta tester systemu FogBUGZ zastanawiał się, czy może on obsłużyć przychodzącego mejla w języku japońskim. "Japońskim? W Japonii mają mejla? Nie miałem pojęcia." Kiedy przyjrzałem się bliżej komercyjnej kontrolce ActiveX, której używaliśmy do parsowania wiadomości email w formacie MIME, odkryliśmy, że robiła wszystko źle, jeśli chodzi o obsługę zestawów znaków, więc musieliśmy napisać heroiczny wręcz kod, żeby odwrócić całą błędną konwersję, a następnie wykonać ją od nowa. Kiedy spojrzałem na inną komercyjną bibliotekę, ona także miała kompletnie spartaczoną implementację kodów znaków. Korespondowałem z programistą tego pakietu, ale on myślał coś w stylu "nic nie da się z tym zrobić". Jak wielu programistów po prostu chciał, żeby to wszystko jakoś zniknęło z czasem.

Ale to nie zniknie. Kiedy odkryłem, że popularne narzędzie do programowania aplikacji webowych - PHP wykazuje się prawie kompletną ignorancją w zakresie kodowania znaków, beztrosko używając ośmiu bitów na znak, czyniąc prawie niemożliwym tworzenie dobrych międzynarodowych aplikacji webowych, pomyślałem wystarczy.

A więc mam pewną rzecz do ogłoszenia: Jeśli jesteś programistą pracującym w roku 2003 i nie znasz podstaw znaków, zestawów znaków, kodowań, Unikodu i złapię Cię, ukarzę Cię, zmuszając do obierania cebuli przez 6 miesięcy w łodzi podwodnej. Obiecuję, że to zrobię.

I jeszcze jedna rzecz:

TO NIE JEST TAKIE TRUDNE.

W tym artykule dostarczę Ci informacji o tym, co każdy pracujący programista powinien wiedzieć. Cała ta gadka, że "czysty text = ascii = znaki mają po 8 bitów" jest nie tylko mylna, ale beznadziejnie mylna i jeśli nadal programujesz w ten sposób, nie jesteś lepszy od lekarza, który nie wierzy w bakterie. Proszę nie pisz nawet jednej linijki kodu więcej, dopóki nie przeczytasz do końca tego artykułu.

Zanim zacznę, powinienem Cię uprzedzić, że jeżeli jesteś jedną z tych niewielu osób, które wiedzą o internacjonalizacji, uznasz mój cały wywód za lekkie uproszczenie. Staram się tak naprawdę wyznaczyć minimum, które każdy będzie w stanie zrozumieć, a które pozwoli na pisanie kodu mającego szansę działać z tekstem w jakimkolwiek innym języku niż podzbiór angielskiego nie uwzględniający słów z akcentami. I powinienem uprzedzić Cię, że obsługa znaków to tylko mała część, która sprawia, że oprogramowanie działa w różnych językach. Jednak mogę pisać tylko o jednej rzeczy naraz, więc dzisiaj są to zestawy znaków.

Perspektywa historyczna

Najłatwiej zrozumieć to wszystko, idąc chronologicznie.

Prawdopodobnie myślisz, że będę teraz mówił o bardzo starych zestawach znaków takich jak EBCDIC. Hmm, nie będę. EBCDIC nie jest ważny w Twoim życiu. Nie musimy cofać się tak daleko w czasie.

ASCII table W pół-pradawnych czasach, kiedy wymyślano Unixa, a K&R pisali książkę Język ANSI C, wszystko było bardzo proste. EBCDIC miał właśnie ujrzeć światło dzienne. Jedynymi znakami, które się wtedy liczyły, były stare, dobre angielskie litery bez akcentów i mieliśmy dla nich kod nazywany ASCII, który był w stanie reprezentować każdy znak używając liczby między 32 a 127. Spacja miała numer 32, litera "A" - 65, itd. To pozwalało wygodnie zapisać znak na 7 bitach. Większość komputerów w tamtych czasach używało ośmio-bitowych bajtów, także nie tylko mogłeś zapisać każdy możliwy znak zestawu ASCII, ale miałeś cały wolny bit, który, jeśli byłeś złośliwy, mogłeś użyć dla swoich własnych, przebiegłych celów: tępacy w WordStar użyli najbardziej znaczącego bitu, żeby oznaczyć ostatnią literę w słowie, skazując WordStar wyłącznie na angielskie teksty. Kody poniżej 32 były nazywane niedrukowalnymi i używane były na przekleństwa. Ok, żartowałem. Były one używane do znaków kontrolnych, tak jak 7, które sprawiało, że komputer brzęczał, albo 12, które sprawiało, że strona papieru wylatywała z drukarki, aby nowa mogła zostać pobrana.

I wszystko było dobrze zakładając, że mówiłeś po angielsku.

oem Ponieważ bajt ma miejsce na maksymalnie 8 bitów, wielu ludzi zaczęło myśleć "boże, możemy użyć kodów 128-255 dla naszych potrzeb". Problem był w tym, że wielu ludzi wpadło na ten pomysł równocześnie i mieli swoje własne koncepcje na to, co powinno pojawić się w przestrzeni od 128 do 255. IBM-PC miał coś, co miało zostać zapamiętane jako zestaw znaków OEM zawierający litery z akcentami dla języków europejskich i trochę znaków rysujących linie... poziome bloki, pionowe bloki, poziome bloki w małymi dyndałkami dyndającymi z prawej strony itd., można było użyć tych znaków linii, żeby rysować fajniutkie pudełka i linie na ekranie, które można było obejrzeć na komputerach 8088 Twoich pralek chemicznych. Tak naprawdę, jak tylko ludzie zaczęli kupować PC-ty poza Ameryką, różne inne zestawy znaków OEM zaczynały być wymyślane, wszystkie używały ostatnich 128 znaków do swoich własnych potrzeb. Na przykład na niektórych PC-tach znak 130 mógł wyświetlić é, ale na komputerach sprzedawanych w Izraelu była to hebrajska litera Gimel (ג), więc gdy Amerykanie wysyłaliby swoje résumés do Izraela przeczytane zostałoby to jako rגsumגs. W wielu przypadkach, jak w przypadku Rosjan, było wiele różnych pomysłów, co zrobić z tymi górnymi 128 znakami, w rezultacie - nie mogłeś niezawodnie wymieniać dokumentów nawet w obrębie języka rosyjskiego.

W końcu ten OEM dostępny-dla-wszystkich został spisany w standard ANSI. W standardzie ANSI wszyscy zgodzili się co do znaków poniżej 128, co było w zasadzie tym samym, co w ASCII, ale było wiele różnych sposobów na obsługę znaków od 128 wzwyż, zależnie od tego, gdzie żyłeś. Te różne systemy były nazywane stronami kodowymi. Więc dla przykładu w Izraelu DOS używał strony kodowej nazywanej 862, w czasie gdy użytkownicy greccy używali 737. Były one takie same poniżej znaku 128, ale różne od 128 wzwyż, gdzie mieszkały wszystkie śmieszne literki. Wersje narodowe MS-DOSa miały tuziny stron kodowych, obsługujących wszystko od angielskiego po islandzki i miały nawet kilka "wielo-językowych" stron kodowych, które rozumiały Esperanto i Galicyjski na jednym komputerze! Wow! Ale posiadanie, powiedzmy, hebrajskiego i greckiego na jednej maszynie było kompletnie niemożliwe, dopóki nie napisałeś własnego programu, który wyświetlał wszystko używając bitmap, ponieważ hebrajski i grecki wymagają różnych stron kodowych z różną interpretacją wyższych numerów.

W tym samym czasie w Azji wymyślano jeszcze bardziej szalone rzeczy, aby uwzględnić fakt, że azjatycki alfabet zawiera tysiące liter, które nigdy nie zmieściłyby się na 8 bitach. To było zazwyczaj rozwiązywane przez koszmarny system DBCS, tak zwany "dwu-bajtowy zestaw znaków", w którym niektóre litery były przechowywane na jednym bajcie, a niektóre na dwóch. Było dość łatwo przeszukiwać łańcuch znaków wprzód, ale prawie niemożliwe przeszukiwać wstecz. Programiści byli zmuszeni nie używać s++ i s--, aby poruszać się wprzód i w tył, a zamiast tego musieli używać funkcji, takich jak AnsiNext i AnsiPrev w Windows'ie, które wiedziały, jak poradzić sobie z tym bałaganem.

Ale ciągle większość ludzi udawało, że bajt to jeden znak, a znak ma 8 bitów i tak długo, jak nie przenosili łańcuchów znaków z jednego komputera na inny albo nie mówili więcej niż jednym językiem, jakoś to niby zawsze działało. Ale oczywiście jak tylko pojawił się Internet, stał się on raczej popularnym miejscem do przesyłania łańcuchów znaków z jednego komputera na inny i cały ten bałagan zaczął się powoli walić. Na szczęście - wymyślono Unikod.

Unikod

Unikod był odważną próbą stworzenia jednego zestawu znaków, który zawierałby każdy rozsądny system piśmienniczy z całej planety, a także kilka egzotycznych jak klingoński. Niektórzy mylnie uważają, że Unikod to to po prostu kod 16-bitowy, w którym każdy znak zajmuje 16 bitów i dzięki temu można zapisać maksymalnie 65536 znaków. Właściwie - to nie jest prawda. To jest najbardziej popularny mit na temat Unikodu, więc jeśli tak właśnie myślałeś - nie martw się.

Unikod ma tak naprawdę inny sposób myślenia o znakach i musisz zrozumieć ten sposób myślenia Unikodu o rzeczach albo nic nie będzie później zrozumiałe.

Do tej pory zakładaliśmy, że litery są mapowane na kilka bitów, które przechowujemy na dysku lub w pamięci:

A -> 0100 0001

W Unikodzie litera jest mapowana na coś, co nazywa się punktem kodowym, który jest koncepcją czysto teoretyczną. Sposób, w jaki punkt kodowy jest reprezentowany w pamięci lub na dysku, jest inną bajką.

W Unikodzie litera A to koncepcja platoniczna. To bujający w obłokach twór:

A

To platoniczne A jest różne od B i różne od a, ale takie samo jak A i A a także A. Koncepcja, że A w czcionce Times New Roman to ten sam znak, co A w czcionce Helvetica, ale inny niż "a" z małej litery nie jest bardzo kontrowersyjne, ale w niektórych językach określenie czym jest litera może powodować kontrowersje. Czy niemiecka litera ß to naprawdę litera, czy tylko bardziej wydumany sposób napisania ss? Gdy kształt litery zmienia się na końcu słowa, czy jest to inna litera? Hebrajczycy powiedzą "tak", Arabowie - "nie". W każdym razie mądrzy ludzi w konsorcjum Unikodu zastanawiali się nad tym przez ostatnią dekadę lub dłużej, wspierani przez wiele wysoko-politycznych debat i nie musisz się już o te rzeczy martwić. Oni już to wszystko rozpracowali.

Każda platoniczna litera w każdym alfabecie jest przez konsorcjum Unikodu przypisana do magicznego numeru, który pisze się tak: U+0639.  Ten magiczny numer nazywa się punktem kodowym. U+ oznacza "Unikod" a następujące po nim liczby są zapisywane w systemie szesnastkowym. U+0639 to arabska litera Ain. Angielska litera A wyglądałaby tak: U+0041. Możesz je wszystkie odnaleźć, używając programu tablica znaków na Windows'ie 2000/XP albo odwiedzając stronę Unikodu.

Nie ma tak naprawdę limitu na liczbę liter, które może zdefiniować Unikod i w rzeczywistości ilość przekroczyła już 65536, więc nie każda litera w Unikodzie może być wciśnięta w dwa bajty, ale to był tak czy siak mit.

OK, więc mamy łańcuch znaków:

Hello

który, w Unikodzie, odpowiada tym pięciu punktom kodowym:

U+0048 U+0065 U+006C U+006C U+006F.

Po prostu kilka punktów kodowych. Liczb, tak naprawdę. Nie powiedzieliśmy jeszcze, jak przechowywać je w pamięci albo jak reprezentować w wiadomości email.

Kodowania

To właśnie miejsce, w którym kodowania wchodzą do gry.

Najwcześniejsza idea kodowania Unikodu, która doprowadziła do mitu na temat dwóch bajtów, to "hej, zapiszmy po prostu te liczby na dwóch bajtach każdą". Tak więc "Hello" stało się

00 48 00 65 00 6C 00 6C 00 6F

Racja? Nie tak szybko! Nie mogłoby to być równie dobrze:

48 00 65 00 6C 00 6C 00 6F 00 ?

Z technicznego punktu widzenia, mógłbym uwierzyć, że mogłoby. W zasadzie najwcześniejsze implementacje wręcz chciały zapisywać punkty kodowe Unikodu w notacji high-endian lub low-endian w zależności od tego, w której z nich szybszy był konkretny procesor, i nim ktokolwiek zdążył zauważyć, już istniały dwa sposoby na zapisanie Unikodu. A ludzie byli zmuszeni wymyślić dziwną konwencję dopisywania FE FF na początku każdego łańcucha znaków w Unikodzie; to tak zwany Znacznik Kolejności Bitów Unikodu i jeśli zamieniasz swoje wyższe i niższe bajty, to wygląda to tak: FF FE a ludzie czytający Twoje łańcuchy znaków będą wiedzieli, jak zamienić każdy następny bajt. Uff. Jednak nie każdy unikodowy łańcuch znaków występujący w przyrodzie ma znacznik kolejności bajtów na początku.

Hummers

Przez chwilę wydawało się, że to będzie wystarczające, ale programiści narzekali. "Popatrz na te wszystkie zera!" mówili, w końcu byli Amerykanami i patrzyli na angielskie teksty, które rzadko używały punktów kodowych ponad U+00FF. Ponadto byli oni liberalnymi hipisami z Kalifornii, którzy chcieli zachować stary porządek (hihi). Gdyby byli z Teksasu, nie mieli by nic przeciwko pożeraniu dwukrotnej ilości bajtów. Ale te kalifornijskie mięczaki nie mogły znieść podwajania ilości miejsca na łańcuchy znaków, a poza tym istniało wtedy tak dużo tych cholernych dokumentów w różnych odmianach ANSI i DBCS i kto je teraz przekonwertuje? Ja? Przez to większość ludzi ignorowało Unikod przez parę lat, a w międzyczasie wszystko się jeszcze bardziej pogarszało.

Dlatego wymyślono świetną rzecz - UTF-8. UTF-8 był kolejnym systemem przechowywania łańcuchów punktów kodowych Unikodu, tych magicznych numerów U+, w pamięci za pomocą 8-bitowych bajtów. W UTF-8 każdy punkt kodowy z przedziału 0-127 jest zapisywany na pojedynczym bajcie. Tylko punkty 128 i wyżej przechowywane są używając 2, 3 aż do 6 bajtów.

How UTF-8 works

To ma ten elegancki efekt uboczny, że angielskie teksty wyglądają tak samo w UTF-8, jak wyglądały w ASCII, więc Amerykanie nie widzą w tym nic złego. Tylko reszta świata musi się namęczyć. Konkretnie, Hello, które zapisywane było jako U+0048 U+0065 U+006C U+006C U+006F będzie zapisywane jako 48 65 6C 6C 6F, które, zaraz! wygląda tak samo jak w ASCII, w ANSI i w każdym zestawie znaków OEM na całej planecie. A jeśli jesteś na tyle głupi, żeby używać liter z akcentami, liter greckich lub klingońskich, musisz używać kilku bajtów, żeby zapisać pojedynczy punkt kodowy, ale Amerykanie nigdy tego nie zauważą. (UTF-8 ma także tę miłą właściwość, że ignorancki, stary kod przetwarzający łańcuchy znaków używający pojedynczego bajtu 0 jako oznaczenie wartości pustej, nie będzie ścinał łańcuchów znaków).

Póki co opowiedziałem o trzech sposobach kodowania Unikodu. Tradycyjna metoda zapisz-to-na-dwóch-bajtach nazywana jest UCS-2 (ponieważ ma dwa bajty) albo UTF-16 (ponieważ ma 16 bitów), ale musisz wiedzieć, jak rozróżnić UCS-2 z notacją high-endian albo low-endian. No i jest nowy, popularny standard UTF-8, który ma ciekawe właściwości i działa nieźle, jeśli masz do czynienia z tekstem angielskim i upośledzonymi umysłowo programami, które są kompletnie nieświadome świata poza ASCII.

Tak naprawdę istnieje wiele innych metod kodowania Unikodu. Jest coś, co nazywa się UTF-7, który jest bardzo podobny do UTF-8, ale gwarantuje, że najbardziej znaczący bit będzie zawsze zerem, więc gdy przesyłasz Unikod przez jakiś drakoński program pocztowy, który uważa, że 7 bitów to wystarczająco dużo, dziękuję bardzo, to nadal znaki mogą przecisnąć się niezniszczone. Jest UCS-4, który przechowuje punkt kodowy na 4 bajtach, co ma tę dobrą właściwość, że każdy pojedynczy punkt kodowy może być przechowywany na takiej samej liczbie bajtów, ale, o rany, nawet Teksańczycy nie byliby tak beztroscy, żeby marnować taką ilość pamięci.

No i teraz skoro już myślisz w kategoriach platonicznych, idealnych liter, które są reprezentowane za pomocą punktów kodowych Unikodu, to te unikodowe punkty kodowe mogą być zakodowane także w każdym z tradycyjnych schematów kodowych! Na przykład, mógłbyś zakodować łańcuch znaków Unikodu dla wyrazu Hello (U+0048 U+0065 U+006C U+006C U+006F) w ASCII albo kodowaniu greckim OEM albo hebrajskim kodowaniu ANSI albo w jednym z kilku setek kodowań, które zostały dotychczas wymyślone, ale z jednym haczykiem: niektóre litery mogą się nie pojawić! Jeśli nie ma żadnego odpowiednika dla unikodowego punktu kodowego, który starasz się przedstawić w konkretnym kodowaniu, zazwyczaj dostaniesz znak zapytania: ? albo jeśli jesteś naprawdę dobry - pudełko. Który znak dostałeś? -> �

Istnieją setki tradycyjnych kodowań, które potrafią przechowywać tylko niektóre punkty kodowe poprawnie, a wszystkie inne punkty kodowe zamieniają w znaki zapytania. Niektóre popularne kodowania angielskiego to Windows-1252 (standard Windows 9x dla języków zachodnio-europejskich) i ISO-8859-1, inaczej Latin-1 (także użyteczny dla każdego z zachodnio-europejskich języków). Ale próbując zapisać rosyjskie albo hebrajskie litery w tych kodowaniach dostaniemy tylko znaki zapytania. UTF 7, 8, 16, i 32 mają tę fajną właściwość, że potrafią zapisać jakikolwiek punkt kodowy poprawnie.

Najważniejsza prawda na temat kodowań

Jeśli kompletnie zapomnisz wszystko, co właśnie tłumaczyłem, proszę zapamiętaj tylko jedną, ekstremalnie ważną rzecz. Nie ma sensu mieć łańcucha znaków bez wiedzy, jakiego kodowania używa. Nie możesz dłużej chować głowy w piasek i udawać, że "czysty" tekst to ASCII.

Nie istnieje coś takiego, jak Czysty Tekst.

Jeśli masz łańcuch znaków, w pamięci, w pliku albo w wiadomości email, musisz wiedzieć jakiego używa kodowania albo nie jesteś w stanie go zinterpretować i wyświetlić użytkownikom prawidłowo.

Prawie każdy problem typu "moja strona internetowa wygląda jak bełkot" albo "ona nie może przeczytać mojego mejla, kiedy używam akcentów" sprowadza się do jednego naiwnego programisty, który nie zrozumiał prostego faktu, że jeśli nie powiesz wyraźnie, czy dany łańcuch znaków zakodowany jest w UTF-8, ASCII, ISO 8859-1 (Latin 1) albo Windows 1252 (Zachodnio-Europejski), nie można przedstawić tego łańcucha prawidłowo ani nawet powiedzieć, gdzie się kończy. Istnieje ponad setka kodowań, a powyżej punktu kodowego 127 - wszystko może się wydarzyć.

Jak przechowujemy tę informację o tym, jakiego kodowania używa łańcuch znaków? Hmm, są na to standardowe sposoby. Dla wiadomości email powinieneś mieć łańcuch znaków tego typu w nagłówku wiadomości

Content-Type: text/plain; charset="UTF-8"

Dla strony internetowej pomysł był taki, że serwer webowy zwróci podobną informację Content-Type w nagłówku http razem z zawartością strony -- nie w samym HTMLu, ale w jednym z nagłówków odpowiedzi na żądanie, które są wysyłane przed stroną HTML. 

To powoduje problemy. Przypuśćmy, że mamy wielki serwer webowy z wieloma pod-serwisami i setkami stron dodawanymi przez masę ludzi mówiących wieloma różnymi językami i używających różnego kodowania, które akurat wymyśliła im ich kopia Microsoft FrontPage'a. Sam serwer webowy nie za bardzo wie z jakim kodowaniem napisany był poszczególny plik, dlatego nie mógłby wysłać nagłówka Content-Type.

Byłoby całkiem wygodnie umieścić Content-Type dla danego pliku HTML w tym właśnie pliku, używając jakiegoś specjalnego znacznika. Oczywiście to doprowadza purystów do szaleństwa... jak w takim razie czytałbyś ten plik HTML, dopóki nie wiedziałbyś w jakim jest zapisany kodowaniu?! Na szczęście, niemal każde dostępne kodowanie tak samo traktuje znaki między 32 i 127, dlatego zawsze możesz dojść przynajmniej do tego miejsca na stronie HTML bez używania śmiesznych literek:

<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Ale ten znacznik meta powinien być naprawdę pierwszą rzeczą w sekcji <head>, ponieważ jak tylko przeglądarka internetowa zobaczy ten tag, przestanie parsować stronę i zacznie ponownie, interpretując wszystko w kodowaniu, które wyspecyfikowałeś.

Co robią przeglądarki internetowe, jeśli nie znajdą żadnego Content-Type ani w nagłówku http, ani w tagu meta? Internet Explorer robi rzecz ciekawą: próbuje zgadnąć, bazując na częstotliwości używania różnych bajtów w typowym tekście w konkretnym kodowaniu, w jakim języku i kodowaniu jest dana strona. Ponieważ starsze, 8 bitowe strony kodowe miały zwyczaj umieszczać swoje litery narodowe w różnych przedziałach między 128 a 255 i ponieważ każdy język używany przez ludzi ma inny charakterystyczny histogram użycia liter w tekście, ma to szansę zadziałać. To całkiem dziwne, ale zdaje się, że działa to na tyle często, że naiwni twórcy stron internetowych, którzy nigdy nie wiedzieli, że potrzebują nagłówka Content-Type, patrzą na swoją stronę w przeglądarce, a ona wygląda ok, dopóki pewnego dnia nie napiszą czegoś, co nie do końca współgra z rozkładem prawdopodobieństwa liter w ich rodzimym języku, Internet Explorer zadecyduje, że to koreański i tak to wyświetli, jednocześnie udowadniając, tak myślę, że prawo Postela, aby "być konserwatywnym w tym, co się wypowiada i liberalnym w tym, co się akceptuje" nie jest, szczerze, zbyt dobrą zasadą inżynierską. No a co biedny czytelnik takiej strony, która napisana była po bułgarsku a wygląda na koreańską (i nawet nie jednolicie koreańską), może zrobić? Idzie do menu Widok | Kodowanie i stara się wypróbować różne kodowania (jest przynajmniej tuzin kodowań dla języków wschodniej Europy), dopóki strona nie wygląda bardziej przyjaźnie. Jeśli tylko wie, że może to zrobić, czego nie wie większość ludzi.

Rose

Do ostatniej wersji CityDesk-u, programu zarządzającego stronami internetowymi opublikowanemu przez moją firmę zdecydowaliśmy się, że wewnętrznie będziemy używać Unikodu w UCS-2 (dwa bajty), czego używa Visual Basic, COM i Windows NT/2000/XP jako swój natywny typ łańcuchów znaków. W kodzie C++ po prostu deklarujemy łańcuchy znaków jako wchar_t ("wide char") zamiast char i używamy funkcji wcs zamiast funkcji str (na przykład wcscat i wcslen zamiast strcat i strlen). Aby stworzyć łańcuch znaków w UCS-2 w kodzie C musisz po prostu umieścić literkę "L" przed łańcuchem tak, jak tutaj: L"Hello".

W momencie, kiedy CityDesk publikuje stronę internetową, konwertuje ją do UTF-8, który jest obsługiwany przez przeglądareki od wielu lat. W taki sposób zakodowanych jest wszystkich 29 wersji językowych strony Joel on Software i nie słyszałem nawet jednej osoby, która miałaby kłopot z ich oglądaniem.

Ten artykuł staje się raczej długi, a nie mogę omówić wszystkiego, co jest do poznania w zakresie kodowania znaków i Unikodu, ale mam nadzieję, że skoro przeczytałeś aż dotąd, wiesz wystarczająco dużo, żeby wrócić do programowania (używając antybiotyków zamiast pijawek i czarów), z czym Cię teraz zostawię.

Data publikacji oryginału: 8 października, 2003

Posty, które mogą Cię zainteresować:

Ergonomia miejsca pracy przy komputerze

Programista-MacGyver

Postępowanie z zakałami projektu

Jedna rzecz, o której powinien wiedzieć każdy programista

Wszystko czego potrzebowałem się dowiedzieć o ...

Shedding Bikes: Programming Culture And Philosophy

I'm currently working on the last few lessons in Learn Python The Hard Way and I want to include a lesson on general health problems programmers run into during their careers. I find many programmers seem to ignore their body's physical state when they're coding, most likely due to the intense concentration required. I'm hoping other people could benefit by simply understanding a few health related problems programming has almost caused me or caused many other people I know, and how I avoided them.

I probably won't put this whole blog post into LPTHW since it's a bit much, but I will make a shorter version of it. Please feel free to let me know if you hate it or like it or if you have some additional resources I could reference.

My Background And Qualifications

In the past I was a top qualified soldier in the US Army, and I have studied many martial arts. These days I'm not as into working out and studying martial arts as I used to be, instead focusing on yoga, meditation, and simpler activities. When I was younger I was incredibly fit, and still am because of habits and practices I ingrained in myself from an early age.

First a quick list of martial arts I've studied for various periods of time: Ninjitsu, Aikido, Judo, Muay Thai, Wing Tsung, Capoeira, and Arnis in no particular order. I would say only Muay Thai is the one I studied most consistently, for probably about 6 years. The others I studied for about 1 or 2 years if I could. I moved around a lot so the only way to study was whatever was in the area.

Also, in the US Army I was at the top of my physical fitness exam, going from barely passing to maximum scores consistently in about 2 years. This involved about 2-4 hours of working out nearly every day if I remember it correctly, which in the Army isn't that difficult. There's really nothing else to do.

Finally, I've been the exact same weight, flexibility, and nearly the same strength my whole life, whether I worked out or not, which means that I probably can't tell you about how to lose weight. I'm most likely genetically predisposed to be this way. That means you should adapt my advice to fit your life and what you've found healthy.

With all that being said, as I've gotten older I much more enjoy the less violent and more "supple" forms of exercise. I feel Yoga is excellent exercise because it's deceptively difficult. I'd also vote for Pilates, swimming, dance, and anything that doesn't cause direct impact on my body. I especially have to watch out for my hands for reasons I'll explain in a bit.

Alright, that should give you an idea that I know something, but more importantly, while doing all of these things, I also wrote software professionally. After getting out of the Army I averaged about 8-16 hours of coding and study a day. I also touch type and I play guitar, yet I've mostly avoided carpel tunnel and other RSI problems.

Hopefully, my experience maintaining my physical health will help you gain some or keep yours.

Common Problems Programmers Face

Programming is a deceptively damaging field to be in, partly because it doesn't seem like you're doing much, and also because of the attitude many programmers have toward their body. You should care about keeping yourself healthy because, when your body is in good shape, that removes "friction" from your mental capacity so that it can focus on important things rather than annoying little problems with your physical wellness.

Obviously the advice on eating right, going outside, getting exercise has been said by everyone. I'm not really going to tell you how to eat, or work out, or how to do a martial art or something else to stay healthy. If you are interested in those things, then please find a professional who can train you and help you.

What I do want to cover are a set of particular problems programmers have from their daily profession. These are just simple really obvious things that for some reason programmers don't realize aren't supposed to be happening:

  • Pain in your wrists from Repetitive Strain Injury (RSI).
  • Problems with your eyes from staring at moving print for extended periods.
  • Back problems from poor posture, especially in the lower back and upper shoulders.
  • Bowel and urinary issues from not crapping and pissing when you should.
  • Dehydration from drinking too much caffeine and not enough water.
  • Problems with hemorrhoids and the prostate for guys from sitting too much. Yep, I'm gonna go there.
  • Vitamin D deficiency from lack of sunshine.
  • Sleeping disorders from staying up late and drinking too much coffee.
  • General stiffness and soreness from a lack of stretching in general.

I've had to struggle with all of these problems at one point in my life because of programming, guitar, or actually from lifting weights wrong. In each case I was able to get healthy and then avoid it the rest of my life, and really only deal with a few problems periodically. You may think some of these are stupid, but believe me, many programmers have these problems for various reasons even if you might not.

The General Cause

Overall the general cause of all of these problems can be summarized as treating programming as an obsession. You may want to be very good at it, like I did, so you exclude everything else in your life in order to master it. You don't go to the bathroom, you have macho 10 hour coding sessions, you don't eat right, and all manner of mythological beliefs about "real programmers".

Truth is real programmers are kind of idiots. They don't eat right. They don't have sex on a regular basis. They can't run without gasping for breath. They have huge problems with their internal organs not caused by disease. Really, it's just not worth it if you have to kill yourself to be good at something.

So, as you read through each of these problems and how I've cured them, remember that it's all about just having a balanced life and not being obsessed with coding or your business. Trust me when I say you will actually become better if you take it easy on yourself and stay healthy.

Wrist Pain

This is probably the one I struggle with the most, because I code and play guitar quite frequently and for long periods of time. I've had pain in my wrists periodically since I started coding professionally at 22, but I always had a set of Aikido exercises I did to get my wrists straight.

You see, Aikido has these fantastic wrist exercises that make your wrists strong and supple at the same time. They developed the exercises to avoid injuries during practice since many of the Aikido techniques involve wrenching, ripping, and breaking the joints in the arms, wrists, and shoulders.

For me these exercises have always fixed any misalignment and pain, and they've allowed me to code for long periods of time without much trouble. Typically the only time I'll have problems is if I've switched keyboards and have a new odd keyboard layout, but if I do I simply do the exercises for about a week every time I go to code and they get strong again.

Now, if you have serious carpel tunnel or another kind of RSI then consult your physician before trying these. If you do them, then start very slowly, and do not try to make them hurt. Stretching should not hurt, it should just be "mildly uncomfortable". If it hurts, then you are straining to do the stretch.

What you actually want to do is relax into every stretch you do. It's hard to explain, but instead of forcing your joint to a certain position, bring it to that position and then think about relaxing it or "letting" it move a bit further.

Keep this in mind, and then here's a set of videos that show you how to do each exercise:

Here's how you use these exercises before you sit down to type (every time!):

  1. First, you need to warm up, so put your hands out in front of you and grab at the air as fast as you can 20 times. Then shake your hands, then rotate your wrists 10 times one direction and 10 times another.
  2. Start with the first exercise you're best at, and do 5-10 of them at a medium speed.
  3. Continue through each one, but after each one shake your hands and arms and rotate your wrists to realign them. These exercises do some moving of the bones in your wrist, so shaking them sort of makes them settle back in.
  4. NEVER do too much strain on your wrists. Do just enough to get them going and feeling supple and relaxed, but the motto "no pain no gain" will only damage you.

Do these each time you go to type, every day, and any time you stop. It doesn't take long to do them, and after a bit of discomfort as your wrists start to adapt and get realigned, you'll start to feel better.

One more time though: DO NOT DO THIS WITHOUT CONSULTING A DOCTOR FIRST You do these at your own risk, so don't sue me if you fuck up your wrists because you didn't pay attention. These exercises have been done for maybe thousands of years in various martial arts, so I know they aren't dangerous but everyone is different. You could screw yourself up bad if you do them wrong, so if it hurts stop doing them and talk to a doctor!

Guitarists Are Worse

Programmers will get RSI but it's nothing compared to what guitarists and bassists get. For various stupid reasons there's myths around many of the big name musicians and their claims of studying "8 hours a day" or "16 hours a day!". Because of this guitarists will kill themselves and damage their hands making it impossible to play.

Guitar is a hard instrument on your hands, so even a little pain can put you out of commission. I learned this the hard way in school because, like an idiot, I believe my instructors when they said I had to study 8 hours a day. I literally thought they meant 8 hours straight, so I did that for about a month and then BAM!

Fucked up my thumb and gave it a bone spur and all my fingers hurt like crazy. My wrists were solid, but my fingers just couldn't take it. Like an idiot I didn't listen to what I already knew which is any new activity has to be gradually increased like any other work out.

The only way I could fix this, and it took nearly 1.5 years, was to do the following:

  1. Find guitars that didn't hurt my hands. The idea that you can "play any guitar" is crap. Get the best guitar you can that doesn't hurt you.
  2. Do the above exercises, and then some more for my fingers.
  3. Start slowly rebuilding my fingers and thumb by doing a set of exercises to improve their strength and relaxation.
  4. Constantly focus on relaxing while playing so that I could use a lighter touch.
  5. Avoid bends as they hurt my hands and caused me injuries.
  6. Changed my position and playing style so that I'm able to move around quickly without having to grip the guitar, instead my thumb is on the back of the guitar where it's comfortable.
  7. Adjusted the height of my guitar so that it was comfortable on my shoulder and hands to play.
  8. Always play standing up now, rarely sitting down for long periods of time because the position is awkward, and if I do I keep the same position.

After doing that for the last year my hands are finally feeling good and have healed up, and I've not got good habits that prevent me from injuring myself. I'm an old guy so these things are important, but that also means I can't do anything that might hurt my hands.

My hands are my life right now, so that means no boxing, capoeira, or anything else I really want to study. I have to much riding on my hands to waste it on a punching bag.

Eye Strain

I think this isn't as much of a problem as it was for me, but you have to watch out for your eyes. I had perfect better than 20/20 vision when I was younger, but from decades of computer use my eyes are "slightly off". I have a minor correction in glasses and these days I just wear them all the time even if I only need them a little bit. The world is just annoyingly fuzzy without them.

Back in the bad old days we stared at CRT screens all day, which had horrible annoying flicker and screwed up quite a few eyes. These days it's not the flicker so much as the poor font rendering on most LCD screens. Thanks to patents owned by Apple (I think) many computers can't render fonts well on an LCD screen. Some folks though think Apple's font rendering looks "fuzzy" so your mileage may vary considerably.

In my case I try to get out for about 2 hours a day and not look at a computer. Either I do something that doesn't involve reading like play guitar, or I go for a walk or to the park. I may not do this for a full 2 hours but I try to not start at a computer screen for at least 2 hours a whole day.

This will also help with headaches you might have. Frequently programmers will think that the lighting in a room is what gives them headaches from using a computer, but really it's bad posture, shitty fonts, not drinking enough water, and just using the computer for too long at a stretch.

Instead of doing some extreme thing like turning out all the lights in your office, just have good lighting and use a color scheme that fits the type of LCD you have and the room's lighting. It's the combination of room/area lighting, LCD brightness, LCD quality, fonts, and your color scheme that will make you feel better.

But most importantly, just take a break.

Back Problems

I've been extremely luck to have a good solid back most of my life. Even though I've been sitting in a chair for a good portion of that life, I still have a good flexible and strong back.

For me, the problem is in my upper back, neck, and shoulders. I tend to hunch over the keyboard and have to force myself to sit up straight. In fact right when I started typing this section I noticed I wasn't sitting up straight and had to correct it.

Now, the choice of chair matters, and I tend to like either Aeron chairs of some kind of solid small stool or bench. I'm currently very much liking my little $40 piano bench I used to sit on to practice piano. It doesn't have a back so it forces me to sit up straight more often and engage my core muscles (stomach and back muscles).

For my shoulders though it's entirely stress. I tend to "scrunch up" my shoulders when I'm focused intensely and that causes my whole upper back to hurt, sending pain all the way up my neck and head. It gets really bad if I practice guitar for long periods at a time.

What I've found helps the most is stretching your upper arms and doing push-ups. Stretching your upper arms is as simple as grabbing a door jam, grabbing it, and pulling each arm or both arms in a different direction. Try these if you're feeling stiff:

  1. Grab a door jam with one arm so your palm faces the front of your body, then pull your shoulder out so you stretch your chest and the front of your shoulder.
  2. Grab the door jam with one arm so that your arm crosses your body, and again with your palm facing the front (kind of backwards), then pull so your shoulder at the back is stretched.
  3. Put both arms on the door jam in front of you, right above your head, and stand away from it a bit so that you lean down and pull your arms above you and back.

If you do that, and also rotate your shoulders and shake your body out you'll start to feel much better. Maybe combine this with your wrist stretches before you work each day.

Another big help is doing some push-ups. I wouldn't do these at work or before you work because it will make you tired and make it hard to work. I'd instead just do 10 a night before you go to sleep. Just 10 will do a lot for your chest, back, wrists, and neck. Don't do them very fast, but do them slowly and focus on balancing your body when you do them.

Dehydration

This one is simple, and I'm guilty of it quite frequently. I find I drink a ton of coffee, and because of that I have to make sure I drink some water too. If I don't I get headaches and really don't feel right. The problem with dehydration is it's hard for you to tell you're suffering from it until it's too late.

What I suggest, and what I've started doing more, is that you drink a bottle or cup of water with every non-water beverage you drink. I also recommend you ditch the sodas. They're just full of nasty fake sugar that make you fat and cause diabetes, and they're not rehydrating you. If you gotta drink something then plain black coffee is pretty damn good, but again drink some water with it.

Bowel And Urinary Problems

Alright the next two are kinda gross so I won't go into what happened to me, but I'll say this:

Go to the fucking bathroom right when you have to go. Don't wait.

You wouldn't believe how useful this advice is and I really wish I'd been told it when I was younger. Because I would code non-stop like a "real programmer" I would skip bathroom breaks and hold it in for far too long. The problem is with bowel movements your body just stops telling you to crap, and then it builds up.

This eventually leads to constipation and it's a motherfucker on your health. For your urinary tract it causes problems that are less important, but you can get infections and other nice little surprises.

If you've already screwed up, the best thing to do is go get some fiber tablets and take them then stay home 'cause it's gonna get ugly.

Then, when you feel you need to go, just get up and go for the love of god. I'm telling you, your brilliant idea will come more naturally after you poop.

Hemorrhoids and Prostate Health

The other problem you have from not using the restroom when you should is that you get hemorrhoids. Yeah yeah, I know, really gross and I promise this is the only time I'm gonna mention them ever. But, many programmers have them and are ashamed to talk about them or even know what causes them so I'm going to lay it out for you. I've actually done all of these but only had them once or twice:

  1. Sitting for a long period of time.
  2. Lifting heavy weights without proper equipment.
  3. Not taking a dump when you actually need to.
  4. Forcing a dump when you don't need to.
  5. The worst one though: Sitting on the toilet reading.

This last one is the killer let me tell you. If you don't have to go, then do not sit on the can hanging out. What this does is put all the weight of your body and bowels on your already probably screwed up rectum and then pushes it out. Nasty. That also then causes hemorrhoids because the pressure increases in your blood vessels unnaturally.

These are just freaking gross, but they're also potentially harmful. Yes, you can get some that are so bad you bleed all over the place. If you have some, please go see your doctor and deal with it. You may need surgery, so just do it. I didn't but man it was close. One year I was lifting weights, working in a warehouse, coding non-stop, and not using the bathroom.

Yep, I was idiot, so don't make the same mistake. Make sure you do these three things to keep your ass healthy:

  1. Eat some veggies regularly, or eat some fiber tablets at least.
  2. Go to the bathroom right when you have to go.
  3. Don't force pressure down there in any way.

This can also damage your prostate if you aren't careful, but usually that's from sitting on your ass all day. Just get up and walk around or take breaks and you'll fix that problem. If you find blood in your urine or you have problems peeing, go see a doctor because it might be more serious. If you pee a lot it can also be bad, so again see a doctor.

Vitamin D Deficiency

Vitamin D is weird. You really only get it from the Sun but you don't need much direct sunlight to get it. Maybe like 5-30 minutes depending on how strong it is. It's also tied to your calcium levels, and a lack of phosphate, but if you eat regularly and something other than potato chips that shouldn't be a big problem.

Some of the things you can get are depression, screwed up teeth, pain in weird places like in the bones in your arms, cramping muscles, and just generally feeling like crap. If you're really bad you might need to get a prescription from a doctor, but usually you can just make a plan to go outside for 30 minutes when the Sun is high in the sky.

In fact, I think this is one of the problems with catered food at many startups here in the Valley. Since you are inclined to stay in the office and eat food and constant leftovers, and because many offices have poor lighting, you tend to not go outside when the Sun is out. Combine that with poor sleeping habits and you can really be screwing up your vitamin D levels without knowing it.

Just something as simple as not eating the catered lunches and walking outside at noon to get your food could help more than you know. Anyway the food is better.

I got minor vitamin D deficiency when I lived in Vancouver and Seattle. Up there you just don't have sunshine for months on end, and for me that was a killer. Some people can handle it, but for people like me who lived on a tropical islands in his teens, this was just murder.

So, if you have sunshine, get out and grab some when you can.

Sleeping Disorders

I've always had a flexible sleep schedule, usually depending on the season and the region. In some areas I trend toward a night owl persona and stay up really late doing things then sleeping in. Lately since moving to SF I've been getting up earlier and not staying up as late, and I've actually been feeling really good lately.

Sometimes though, and I'm not sure why, I feel way more productive in both music and coding late at night, or very early in the morning. I think it's because I'm still in a tired state and so my brain is relaxed. I also think it's because it's very quiet and I can just hang out and think with no distractions.

Either way, this need to either get up very early or stay up very late sort of screws with my sleep schedule. I find that I much prefer getting up early as I get older. I feel more awake and rested during the day. If I stay up late and sleep in I feel like I have a hangover and I can get headaches.

If you have problems sleeping though, I have a very simple kind of meditation that I've been using for years to help you crash. It takes a bit of practice, but it totally works and works quickly.

First up, if you can, get the best damn bed you can afford. 2000+ dollars is nothing for a great bed. I spent at least 2200 on a sweet Tempur-Pedic. It's totally worth it.

Now with your awesome bed here's how you start practicing getting to sleep easily. It's kind of a self-hypnosis trick:

  1. Make sure that you've killed all sounds and lights that might be in your room.
  2. Lay on your back and put your hands on your body somewhere comfortable, or at your sides.
  3. Start breathing in deeply and slowly and breathing out, as you do this imagine you can see the air flow in and out of your body.
  4. Once you start to see your breath, imagine that you're looking through a window and outside the window is a large huge open space with stars in it.
  5. As you breath feel yourself float through the window and slowly out into the massive expanse of stars, all floating softly around you.
  6. Keep this going and then just let this floating spread into your bed and out around you until there is nothing.

You probably will crash out at around 4 or 5, but if not just hang out and keep letting yourself float and melt until you do.

If you have severe insomnia then definitely talk to a doctor about it, but try this out, as well as exercising like crazy for about an hour or two a day. Exercise will definitely make you sleep.

Stiffness And Flexibility

If you constantly feel "stiff" or unable to move well, then you probably need to stretch regularly. Really the best thing you can do is go to yoga about once a week, and then try to do the exercises on your own. If you can't do that, then go get any number of books on basic stretching from the library or from a book store. You really just need a simple book on the subject, and you don't need to do too many.

I think if you did about 5-6 big stretching exercises a night before sleeping you'd feel very relaxed and see a major improvement in your general health and feeling.

Relaxing your body through stretching relaxes your mind as well, so a great way to improve your creativity and boost your ideas is to do yoga or stretching for about 30 minutes, then take your morning shower. Combine this with some meditation and you'll start to see a major improvement in your general ability to mentally adapt and start to see yourself make odd connections you wouldn't have before.

I'm not sure why this is, but a relaxed mind is crucial to spontaneous creativity and idea generation.

A Simple First Step

This is probably a lot of information for one person, and I seriously hope that you don't have all of these problems. What I recommend though if you don't have these issues is that you try to avoid them. If you're just starting out then you need to maybe adopt a simple "coding warm-up" routine you can go through before you code.

Here's what I do before I sit down to code, or before I play guitar, and whenever I get stiff and need a break:

  1. Rotate all the joints in your body by just moving your wrists, arms, neck, back, and hips in a few little circles. Say 5 one direction, then 5 in another direction.
  2. Do a small number of the wrist exercises and shake your wrists between each set.
  3. Stretch your arms above your head as high as you can, and then stretch them back as far as you can, and then pull them across the front of your body.
  4. Finally, carefully use your hand to pull your head to the right, left, forward, and back a bit.

If you just did this you would avoid quite a few programming injuries. Since programming isn't really that physically taxing it's fairly easy to avoid hurting yourself, so this is really all you need.

However, if you have a specific problem, then again consult a physician and try some of my advice if they say it's alright. Nothing I'm proposing here is radical or weird, just basic exercises and common sense, so it should be alright with any doctor. I just don't want to get sued so remember I told you to ask one first.

Hopefully that helps you out, and if not just remember the advice in case you run into these. If you're lucky they won't be a problem but I think every programmer I know has had something like this at least once.

If you have other problems along these lines, then feel free to email me and I'll reply with some advice.

Take care.

Contemplative Programming: Interview on Contemplative Programming

Interview on Contemplative Programming

Recently, Frank Westphal conducted an interview with yours truly. Originally, the interview was in German and published as part of Frank's Tonabnehmer ("pick-up") podcast. After some rough and ready translation work, here's the transcribed interview.

F: Hi Greg!  I appreciate your taking the time from your busy schedule for this phone interview. I know you also speak German. Would it be okay if I addressed you in my mother tongue?

G: Hello, Frank. Yes, sure. I speak a little German. You know, I have lived in several countries in recent years.

F: Tell us a bit about yourself! Only very few listeners will have heard of Greg Woydnilek. What's driving you?

G: Driving is not really the right word. Because I recommend something we call "Contemplative Programming". You know, most programmers are always under stress -- very extreme. That's no good!

We not only want to achieve good code and good programs. We also want good programmers who feel well. We say: "Be one with your code" and "Be kind to your code". That's for the first part. The second, more important part, is "Be kind to others and yourself", because first of all we're concerned with people.

Sometimes I'm reminded of an anecdote told by the eminent philosopher Bertrand Russel. In the 1930s he noticed how American and German naturalists reported on animal behaviour. In the americans' reports, the animals are running around and there's always a lot of action. In the Germans', reports the animals are sitting and thinking -- almost like this famous Rodin statue. You see, I have been in America for a couple of years, but I'm a European and have lived here most of the time. I'm not surprised that Extreme Programming originates in America and Contemplative Programming emerged in Europe.

The Americans are learning, though. I think it was [Pete] McBreen, who told of a programmer who didn't hammer on his keyboard wildly, but looked at the ceiling. His boss in outrage asked him what he was doing. To that he [the programmer] answered: "I'm thinking". -- You see, that is it! That's the Heart of Contemplative Programming.

F: Programming by contemplation. My dictionary says: Contemplation - concentrated-introspective cogitation and mental immersion into something. How are we supposed to picture this? Do contemplative programmers enter some kind of trance state?

G: No, no, that's not how it is, of course. Just as little as Extreme Programming has to be extreme all the time. We are not programming Yogi Flyers. So, what we intend to emphasize is the value of thinking [Nachdenken] and advance thinking [Vordänken] -- actually, thinking in general. What have I just done? What have we done in the project recently? Has it been successful? Can we improve on it? We differ from other approaches in that we don't only do this kind of retrospective post mortem, when everything is dead. Rather, we conduct Continuous Retrospectives. It goes so far that we even do Prospective. Only short-term, of course, for even Contemplative Programming is no crystal ball.

An important difference compared to other methods -- and here I'm thinking of XP and RUP and so on all the same -- is that we Contemplative Programmers stay much more relaxed. Relax, there's more to life than work! Kent Beck once wrote that Extreme Programmers get home tired in the evenings. Contemplative Programmers then are still fit for the important things in life. Believe it or not, but Contemplative Programming has improved the love life of lots of practitioners, for real, whereas XP constantly talks about practices -- we do it for real!

I don't intend to conceal that there are critics. An Englishman, of all things, Rosendorn or something. He calls us Lethargic Programming. I'm sure he's just envious.

F: How much post and advance thinking [Nachdenken, Vordenken] do contemplative programmer indulge in in practice? You may have guessed it: It instantly came to my mind what we extreme programmers sneer at as BigUpFrontDesign, or more picturesquely: BigFuckedUpDesign. How do you make sure that, at the end of your relaxed day, you get executable code, not just relaxed thoughts?

G: O no! Jeer all you want. We'll visit you in hospital after your heart attack. But let's not quibble. In fact our positions are pretty close. Contemplative Programming is about Business Value as much as XP is. However, XP appears to be overly fixated on thinking at the keyboard and in the code. We take the liberty to spend the time it takes to consider a question thoroughly. No action, just thinking. We easily take a few minutes for this. And when we realize that we're stuck, then we defer a problem until the next day and take care of something else. The point is that we don't force progress, we encourage it.

F: How about Pair Programming? Do you do it? Do you like it?

G: First of all, I need to set straight a misconception. We Contemplative Programmers are no homogeneous group. We're a variegated mix. Yes, that describes it pretty well. Contemplative Programming rather is a mixin, an aspect. Quite a number of us really like XP. With some concerns, though, they want to intercept and apply an advice, an aleck, that is, to the base method. This way we break the Tyranny of the Predominant Method and keep our peace of mind.

So, to get back to your question. Yes, sure, some [Contemplative Programmers] like Pair Programming, others don't.

F: Contemplative Programming has gained a considerable number of adepts in recent years. Definitely caused by lots of developers being fed up with the predominant methods. They feel burned out by their jobs. And the fun, the reason they became programmers in the first place, has died off over the years.

That's why people try to lead their lives more mindfully. People are more sensitive for their work-life balance, how it is trendily called. Regarding this, Contemplative Programming appears to be consequential.

G: Yes, exactly. I'm no longer burned out from my work. Instead, I have sore muscles from workout. You don't grow any younger [Man wird nicht jünger], or how do you say in Germany? Nonetheless, I prefer the aching muscles by far.

F: Let's get back to the motto: "Be kind to your code". How are we supposed to understand that?

G: First and foremost, it is meant as an admonition against thoughtlessness. You have to realize that there are still hordes of programmers doing something they call "churning out code" [Code raus hauen]. That's exactly what the code looks like: thrashed. Disfigured into a monster, a Behemethod. Well, okay, they don't feed on small children, but often they play bad pranks on the next programmer.

That's not good, but what can we do about it? Well, many of us Contemplative Programmers think that code needs a good upbringing. That calls for empathy and oftentimes leniency, too. That's what we mean by "kindness". But no laissez-faire! We set firm limits through unit tests, like you Extremists do. In contrast, though, we don't think of harnesses or corsets or similar coercives. Our notion is of a sturdy pole where a young tree can grow up straight. The Java programmers can think of a bean pole.

F: Yes, I know exactly what you are talking about. How do you handle the conflict when you very thoughtful people come or work together with those code-churning programmers? Does this conflict exist? How do you go about it?

G: Indeed, there is a lurking conflict. It's only kept from erupting because lots of Contemplative Programmers have stayed under cover. But that we are going to change! I'm currently working on a somewhat theoretical book, tentatively titled "Contemplative Programming Considered". An associate is working on a practical book, presumably titled "Contemplative Programming for Fun and Profit". The later book addresses questions like yours in particular.

So, what do we do? There are quite a few options. By our presence alone we exert a calming influence on our coworkers. Where that is not sufficient, there are kinds of tea with a desirable effect. In cases where even that doesn't work, we demonstrate the advantages of Contemplation. While the others are hacking off their butts, we look for the right way with a clear mind. You probably know the fable of the hare and the hedgehogs? ... When the hacktic finally crosses the finishing line we're already there. At least one of us.

F: Up to now, most of your ideas have been handed down by word of mouth. Those in the community know each other. In the near future, we're going to see the two books on the subject. What can an interested listener do to find out more today? When I search with Google, I hardly find anything.

G: Right, that's been true so far. Publicly we kept very quiet. For the most part our discussions are going on in private forums and mailing lists. But we're in the process of opening. Hence this interview, hence the books. Nevertheless, we intend to proceed without haste. So we don't suffer what we've witnessed in the case of XP. If we, too, step out into the street at high noon, we only provoke the gunslingers. They're only looking out for something to gun down with their twitchy fingers. We endeavour to be a bad target.

That way it'll take somewhat longer until Contemplative Programming makes it into the mainstream, admittedly. But we're not in a hurry. Sustainable Development, that's what counts.

F: Do you have any advice for novices?

G: First of all they ought to work on becoming good programmers. Know your tools. Keep your eyes open. Don't be narrow-minded, but always prepared to learn something new. In my childhood there was this mean piano teacher, Dr. Terwilliker, who had one true sentence: "Practice makes perfect." That's true for all keyboards.

Specifically regarding Contemplative Programming, I'd like to add that doing alone does not lead to happiness. It's of paramount importance to reflect on what one has done. Was it good? What wasn't good? How can we improve it? In short: Learn from your mistakes. Even better: Learn from the mistakes of others.

F: Have you been born with this contemplative streak? Or what has made you into such a reflective practitioner?

G: No, unfortunately it wasn't that easy for me. I've been young, too, and a little bit impetuous. Accordingly, I, too, have experienced what it's like to believe in cracking problems with infinite power. Then it's only a matter of time until burn-out. I wasn't hit that hard, in fact. But it was hard enough so that I didn't take any enjoyment in computers for two years.

I'm not the only one who fared like this. People tend to be embarrassed by it and they don't talk about it. But, cross your heart, once you've grown older than twenty-five, you're cured of thinking it's cool to work yourself senseless. Enthusiasm and commitment are great, of course. But definitely not when they destroy you. -- There has to be another way, for that one's a dead end.

F: Uh oh, how true! Last year I had the chance to experience this myself.

Say, Greg, does Contemplative Programming only relate to us geeks? How about managers, domain experts, testers and all the others hanging about in software projects? Any food for thought?

G: Well, if you look closely, Contemplative Programming isn't about geeks. There's no antagonism, but no positive feedback either. In this conversation I've pointed out the relationship to software development and the name "Contemplative Programming" refers to it, after all. However, the ideas are much more general -- and hardly new at all, I have to add. But as it is, I'm not about to promulgate a Weltanschauung, much less a doctrine of salvation for all. I talk about areas where I have first-hand experience. As it is, that's software development. -- Anyway, I won't hide that I enjoy it when other project members are contemplatively enlightened.

F: Possibly the best project manager I know makes his round in the evening and throws out all his people. He's pretty extreme: He goes so far to switch off the power.

Are contemplation and work-life balance the two forgotten practices that must not be missing from any software development process? Simply to remind us programmers, sitting self-absorbed in front of the screen, that there's our body and beloved ones to care for just as well as our code and computer?

G: I've been wishing for a project manager like that in my earlier days, too. Back then I had a coworker who I often met in the office early. He had been there all night.

Regarding work-life balance I'm ambivalent. It's an important issue for sure. Everyone should heed not to overbalance. But I'm getting uneasy when a business or process mandates how I have to keep my balance. Something like that can be not enforced, but it has to be facilitated.

F: Any famous last words?

G: How about "Stay alive"? Yes, that sounds good.

posted by Gregor Woydnilek at 00:04

Make sense for me, I think that I work this way from the beginning...