Client JavaScript data storage

Cross-browser data storage made easy using PersistJS. It supports a lot of different ways of storing data on client browser, falling back to plain old cookies, when necessary. The library itself is really minimalistic and standalone (opposed to Dojo Storage, for example). Also, it can be integrated with another lightweight runtime storage solution called "Taffy DB", which will enable almost SQL-like queries in JavaScript. Looks very nice to store some user-related info, session data, etc.

Ultimate Pomodoro?

What is the major problem of using the Pomodoro Technique? I think it's a sharing one. You see, when you're "in the middle of a pomodoro", no one really cares - your team mates will go on interrupting you anyway!

So, you need to synchronize it somehow. Setting a single timer per team is a bad idea, for the obvious reasons. What I suggest to do is to invent some kind of a Pomodoro Server and track your current status there (team-wise or project-wise). Of course, the policy should be invented for all team members to check this status before interrupting another person.

Sample feature list:

• Notification when required person's pomodoro has finished
• Integration with your corporate favourite IM client as a plugin
• Integration with popular issue tracking systems via plugins
• Speach recognition to simplify items entry
• Flexible hotkeys for all frequent actions to make things even easier
• Statistics gathering to analyze and boost personal productivity

Hope to find some time to figure it out in a further detail... Frankly speaking, already tried some of the most popular open source voice recognition tools. It seems that either my microphone, or my English, or these tools, or its' settings, or alltogether are too bad to recognize anything but "one [pause] two". With 25% accuracy. Sigh...

About coding

I want to separate two different kinds of coding.

First is handwriting code from scratch, which is a good old not-reusable-bad-to-support approach. It gives me a great pleasure, because I know what to expect and when I solve a Task, it's clear what I've done to complete it. I mean, it's all so clear and predictable, that nothing can spoil your pleasure of getting things done. I used to code this way somewhere about seven years ago writting C++ utils in MS Visual Studio 7.

Nowadays, things are different. I'm developing Important Enterprise Java Applications, and the coding development sequence looks like this:

1. Find an appropriate Library or Framework.
2. Choose the one which either the trendiest one (in this case all your further actions will be more painful), or the wider used one (of course, in this case everyone will think that you're starting to lose your grip on modern hi-tech).
3. Try it on some sample application (though, this stage will not give you any useful information at all).
4. Try to plug it to your existing application, consisting of Frameworks, Libraries and running on Servers. Configure it (that's where you start hating both XML and lazy developers who suddenly appear not being able to write any meaningful documentation at all). That's where the vast majority of time gets spent.
5. Fix all bugs and side effects brought by that all-new yet-another Framework. You won't be able to spot all of them fast enough of course, so this stage virtually never ends.

So, in this world the pleasure of getting things done is usually comes at step 4, when you finally manage to squeeze your brand new part into the puzzle. But that's not it - it has nothing in common with the first Predictable Big Pleasure, and this makes a huge problem for me. Somehow, programming (which is such an interesting and exciting thing in fact!) doesn't make me happy anymore - it became just a job.

And exactly that's why I'm really looking forward to start coding in Ruby, to see if it's that good, as they say.

web.xml security limitations

It appears that web.xml security is kinda useless in the real world - it has few severe limitations:

• This will not work at all (several wildcards):
  <url-pattern>/stations/*/departure/*</url-pattern>
  
  
• This will not work as expected, because only one security constraint will be checked (both constraints work separately):
  
<security-constraint>
<display-name>Station 14 constraint</display-name>
<web-resource-collection>
<web-resource-name>All station 14'th resources</web-resource-name>
<url-pattern>/stations/14/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>STATION_14</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<display-name>View arrival constraint</display-name>
<web-resource-collection>
<web-resource-name>View arrival page</web-resource-name>
<url-pattern>/stations/14/arrival/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>VIEW_ARRIVAL</role-name>
</auth-constraint>
</security-constraint>


Had to spend three days to figure it out :( Now I'm going to investigate Spring Security (AKA Acegi Security).

Mercurial vs Subversion

Mercurial is yet another version control system. According to its' book, here are the main differences to Subversion:

• Mercurial is distributed, i. e. each Mercurial client has his own complete copy of repository, including whole history. That's the main difference to Subversion, which is client-server, so other differences can be considered as side-effects of this.
• Merge is much better in Mercurial, which makes it easier to use branches (always a big pain with Subversion). This is really required, because it's the main mechanism of sharing code between developers.
• Performance - Mercurial is in general somewhat faster.
• Space - Mercurial is more efficient when consuming disk space.
• 3rd-party integration - Subversion has more integration means, at least now.
• Locks - Subversion provides locking mechanism, which is suitable for working with large binary files. Mercurial is not that efficient in this respect, also due to its distributed nature.
• Import/Export - Mercurial is able to import and export data from Subversion, CVS, git and others. It makes it easier to migrate to.

A simple way to start with Mercurial (at least for Windows users) is to download TortoiseHg installer for Windows (all included).

Also, Bazaar should be considered as an alternative (here is a good article comparing and explaining those). Yes, Mercurial appears to be much simpler in install and more than 2 times faster than Bazaar for nearly all operations.

Complete stack of Redmine

When installing Redmine (which seems to be a nice alternative to Trac), I found a site where you can download complete stacks of different open source software, like LAMP, Trac, etc. Should be very useful when one needs a basic fast installation. Versions there are more-or-less fresh (i. e. 0.10.4 for Trac and 0.8.1 for Redmine).

Trac + Subversion installation on Windows

Here I'll describe a 20 minute procedure of Trac + Subversion (the latest versions) installation for 32 bit Windows (successfully tested under Windows XP and Windows 2003 Server). It's really simple and straightforward.

I assume the following directory structure (my project is called "rw"):

D:\projects
D:\projects\trac
D:\projects\trac\rw
D:\projects\repos
D:\projects\repos\rw
D:\projects\tools
D:\projects\tools\Python25
D:\projects\tools\svn-win32-1.5.5

Well, let's get started!

1. Subversion server setup

There are two ways to install SVN server. I tried both of them and both work fine, so it's up to you which one to choose.

1.1.1. Download VisualSVN server
1.1.2. Download SVN binaries (also see complete downloads list)
1.1.3. Download Python bindings for Subversion (at the same place)
1.1.4. Install VisualSVN to any location, set repositories location to d:\projects\repos (you can accept defaults for all other options)
1.1.5. Create a repository (you can use management console for this) named "rw" and check a special checkbox to create a standard folder structure (trunk, tags, etc)
1.1.5. Create a new user for accessing repository. Now you can browse it using this URL and newly created login: https://localhost:8443/svn/rw/

OR

1.2.1. Download SVN server from tigris.org (also see complete downloads list)
1.2.2. Download Python bindings for Subversion (at the same place)
1.2.3. Unzip SVN server to d:\projects\tools, optionally add its bin folder to PATH
1.2.4. Create a repository named "rw" (svnadmin create d:\projects\repos\rw) and create a standard folder structure (trunk, tags, etc) manually
1.2.5. Create a new user for accessing repository (modify D:\projects\repos\rw\conf\passwd and uncomment a line in D:\projects\repos\rw\conf\svnserve.conf). Now you can browse it using this URL and newly created login: svn://localhost/rw/
1.2.6. You can start the server like this: svnserve.exe -r d:\projects\repos -d

TODO: See how it can be tunelled through HTTPS, also see how it can be run as a service.

2. Trac setup

2.1. Download Trac for windows installer (see complete downloads section)
2.2. Download Python 2.5 installer (details here, if needed)
2.3. Download genshi installer for Python 2.5
2.4. Download setuptools (instructions available here)
2.5. Install Python, for example to d:\Python25
2.6. (Optionally) add d:\Python25 to PATH system environment variable
2.7. Install setuptools, genshi and Trac to default locations

3. Integration with Subversion (this solution is kinda ugly hack. I assume it could be achieved much easier, though I was unable to find how exactly):

3.1. Unzip svn-win32-1.5.5_py.zip to d:\Python25\Lib\site-packages
3.2. Unzip svn-win32-1.5.5.zip\svn-win32-1.5.5\bin to d:\Python25\Lib\site-packages\libsvn
3.3. copy d:\Python25\Lib\site-packages\libsvn\*.dll d:\Python25\Lib\site-packages\libsvn\*.pyd
3.4. mkdir d:\projects\trac\rw
3.5. Execute this: trac-admin d:\projects\trac\rw initenv, enter the project name and d:\projects\repos\rw when asked for Subversion repository location. Leave all other values default.
3.7. To test installation just execute this: tracd --port 8000 d:\projects\trac\rw

4. Setup authentication (see instructions)

4.1. Create a new file named trac-digest.py and fill it with code from this page
4.2. Create an administrator user (user "adm" with password "adm"): python trac-digest.py -u adm -p adm >> d:\projects\trac\rw\digest.txt
4.3. Give that user all permissions: trac-admin d:\projects\trac\rw permission add adm TRAC_ADMIN
4.4. Run this to test everything: tracd -p 80 --auth=rw,trac\rw\digest.txt,trac trac\rw

Now you should be able to see the Admin tab if you log in with "adm" / "adm" (see http://localhost/rw)

4.5. Adjust attachment limit in trac.ini:

[attachment]
max_size = 262144000
(it's 250 Mb)

5. Enable automatic ticket control via Subversion comments. See instuctions:
Download trac-post-commit-hook and trac-post-commit-hook.cmd from here and follow instructions in trac-post-commit-hook.cmd.
Place it to d:\projects\repos\rw\hooks and modify .cmd file like that:
SET TRAC_ENV=D:\projects\trac\rw

6. Update. Use Subversion authentication in Trac.
Using AccountManagerPlugin we can work with Trac users fast and easy. I'll describe the simplest and unsecure way of setting it up.

6.1. easy_install http://trac-hacks.org/svn/accountmanagerplugin/trunk
6.2. Go to Trac Admin tab and enable Account Manager Plugin and the following modules:

• AccountManagerAdminPage
• AccountManager
• AbstractPasswordFileStore
• HttpAuthStore
• AccountChangeListener
• AccountChangeNotificationAdminPanel
• SvnServePasswordStore
• AccountModule
• LoginModule
• RegistrationModule

(it will make your life much easier allowing not to login into that Windoze box to change some passwords).
6.3. Now you'll need to add the following line to [components] section of trac.ini (it will disable HTTP authentication):
trac.web.auth.LoginModule = disabled
6.4. Go to Accounts / Configuration (see left menu in Admin mode) and enter your passwd filename into SvnServePasswordStore box (i. e. D:\projects\repos\rw\conf\passwd)
6.5. Now you can login as adm (don't forget to add this user to your Subversion's passwd file) and add / remove Trac users via new menu items in Admin tab. The best thing about it is that now all your changes will be reflected in Subversion configuration, so this could be considered as the common place of manipulating users for your development environment.
6.6. IMPORTANT. Now you can't use --auth when starting tracd. So, my command line is simply tools\Python25\Scripts\tracd.exe -p 80 trac\rw

Now you can customize all the necessary settings, first of all authorization. Also there available a lot of useful plugins for Trac, see Trac hacks site. What I'm going to do next is install Maven proxy and Hudson continuous integration solution.

P.S. The best thing about this installation is that it can be done once and then packed into a handy (in my case 80 Mb) redistributable ZIP file and use it everywhere. The only issue in this case is that you will need to install Python anyway (because of some shared DLLs), but during installation you can choose the existing D:\projects\tools\Python25 directory and it won't override your changes.