Category development

DevOps?

After writing about Taco Bell Programming I discovered that there is a new movement called “DevOps” which goes into the same direction:

Let’s face it – where we are right now sucks. In the IT industry, or perhaps to be more specific, in the software industry, particularly in the web-enabled sphere, there’s a tacit assumption that projects will run late, and when they’re delivered (if they’re ever delivered), they will underperform, and not deliver well against investment. It’s a wonder any of us have a job at all!

The Devops movement is bold enough to believe that there’s a better way – a way of building teams, and building software that can solve these problems.

Read the full DevOps article.

Taco Bell Programming

32 concurrent parallel parsing processes and zero bullshit to manage. Requirement satisfied.

Lots of work can be achieved by using existing tools… so use them, even if they are not fancy, new or hip. That’s true Unix Zen!

Read the full article.

Dojo and fixing bugs

After complaining about Dojo taking so long fixing bugs I found another quite interesting bug report this morning:

Dojo Bug 7844:

  • Filed almost 2 years (!!!) ago
  • Filed against Dojo 1.2
  • Not fixed with the latest 1.5 release, but moved to 1.6 now

Yes, fixing the dojo.back in IE8 is definitely harder than the 1/2 line fix for 8546, but in the end dojo.back is “supported” since Dojo 1.0, so I’d expect that Dojo is tested against new browsers and bugs are fixed in a timely manner…

Upgrading WordPress is super-simple!

Recently WordPress 3.0 has been released so I went ahead and upgraded my WordPress installation to that new version. How hard can it be?

Well, it was super-super-super simple… I’ve never experienced such a painless upgrade for any Web application I ever used. Just click one button, enter the FTP credentials and let WordPress upgrade itself. After upgrading WordPress prompts for a few changes (all written down here) and the whole thing just works. It is as simple as using an Apple product!

So congratulations dear WordPress, for the new, great release and the fact that you take care about your users!

iBatis and DB2 INSERT statements

iBatis for Java is a good way of abstracting away the SQL statements from the business logic; it relies on XML files which contain all SQL statements and it is pretty simple to access a database. Because accessing DB2 from Java is pretty new for me I had some troubles finding a sample to setup a “insert” statement which returns the last inserted ID.
With PHP I’d use my_insert_id(), but how does it work with Java and DB2? Unfortunately all samples I could find where either based on Oracle or on the Microsoft SQL Server…. no luck.

So here is the XML required for an INSERT statement with iBatis on DB2:

<insert id=”insertTABLE” parameterclass=”TABLE”>
INSERT INTO TABLE
(…)
VALUES
(#…#)
<selectkey resultclass=”int” keyproperty=”id”>
SELECT IDENTITY_VAL_LOCAL() as ID FROM SYSIBM.SYSDUMMY1
</selectkey>
</insert>

After that the insert statement can be used like follows:

TABLE_BEAN table_bean = new table_bean();
table_bean.setXXX(…);
mySqlMapClient.insert(“insertTABLE”, table_bean);
// now table_bean.getId() returns the correct id

From now on iBatis works like a charm and the object value is automatically updated… nice!

Software development education is screwed

Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?

Well, I could not agree more. Most students and new-hires do not know to work in a team for longer than a night (the last night before the deadline). And unfortunately a single, long night with energy drinks does not require source control or anything else that is required in real-world code in a real-world team…

Read the full article on JoelOnSoftware.

Unit-tests are way cool!

Unit-tests are what saves a developers ass – and each app should have them, if it makes sense. So it depends :)

But for the project I’m working on right now it made sense, the perfect subject for unit testing. Or do you remember almost 100 different cases and conditions which might break if you change code? In my case I rewrote about 30% of the servlet code to be better structured and being capable of implementing a new requirement. Large parts where Spaghetti code without class inheritance or good usage of objects… subject to be thrown away or rewritten.
After trying the code for the first time after the rewrite the simple, LWP based unit tests immediately showed me where I had to “tweak” the code – and now that they again show a green PASSED I’m confident that it really works in production as well.

That’s how it should be – being confident that changes did not break any other part of the code.
Unit tests are way cool!

Debugging using Apache as proxy

While the follow up article of “Must-have tools for HTML, JavaScript and AJAX development and debugging” (which has also been translated to Chinese, Japanese and Korean) is not written yet I want to share a useful trick that helps debugging live Web applications by injecting custom files into them.

The problem is how to test a new version of a JavaScript library on a production system without even touching the system itself in any way. Testing with local copies of the HTML pages work fine for a few files but does not scale very well, and staging systems might not be properly configured or really tell you if something works on the production system (bugs always just happen in production, right?).
Another problem with debugging JavaScript on production system is that the files might be compressed, which makes debugging in Firebug almost impossible – variable names are shortenend and line numbers don’t make sense any more – would be great to have the uncompressed version instead…

The solution is using a local proxy and replacing certain requests with local files. That way custom files can be injected based on regular expressions and tests can be performed on the production site or even on sites without access to the system itself.
While Fiddler works great on Windows and Charles Proxy does the same on OSX I want to present the poor man’s solution which makes use of any local Apache installation (i.e. MAMP).

The required changes in the httpd.conf are:

# Enable proxy requests
ProxyRequests On
ProxyVia On
<Proxy *>
# Secure the proxy to allow localhost requests only
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1

# replace some files with local copies
RewriteEngine On
RewriteRule myfile.js http://localhost:8888/test/myfile.source.js [P]

# Disable caching
ExpiresActive On
ExpiresDefault “now”
</Proxy>

Lets go through the changes line by line:
The first two lines enable the Apache Proxy support (ProxyRequests On); the <Proxy *> block then configures the proxy further. As stated in the documentation multiple times it is a good thing to secure the server, that’s why only access from localhost is permitted. The important part are now the RewriteRules – they proxy certain requests to the local server instead of the remote server, in the sample above all requests that contain myfile.js will be replaced by the version served from the local server. This could as well be any other remote machine serving the file, as the request is proxied again ([P] flag). Finally caching is avoided by setting all files to expire right now (while this adds more load to the proxy it is not that bad to do during testing).

Now the proxy has to be used in the browser or application of choice; once the proxy settings are changed within the networks settings the access log of Apache should become quite busy when browsing around and, depending on your mod_rewrite settings above, some requests should be replaced with the local copy of a file, making debugging way easier.

Of course the drawbacks of the poor man’s solution are that Apache has to be reloaded in case the RewriteRules change and changing the configuration is not as comfortable as with the dedicated proxy solutions mentioned above. Nevertheless this solution works, is fast and very reliable… and free :)

SVN AuthzSVNAccessFile woes

Setting up AuthzSVNAccessFile support for Subversion (SVN) should not be that hard, right? Plenty of documentation exists… but there is one pitfall – if you define access for certain repository directories make sure the path does not contain a trailing slash!

If you don’t you will see this error message:

Sending folder/design/readme.txt
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for ‘/myrepos/!svn/ver/501/trunk/folder/design/readme.txt’
svn: Your commit message was left in a temporary file:
svn: ‘/tmp/trunk/svn-commit.2.tmp’

Here is a simple AuthzSVNAccessFile sample file showing the issue:

[groups]
developers = mike, peter
designers = marc

[/]
@developers = rw
* = r

# This will not work!
[myrepos:/trunk/folder/design/]
@designers = rw

# Just leave out the trailing slash!
[myrepos:/trunk/folder/design]
@designers = rw

But it’s always just a comma, right?

Can you find the bug?

Yesterdays bug within the MANIFEST.MF file made me remember another bug that took quite some time to fix… let’s see if you can discover the bug in these three lines of code:

// domdoc is a DOM document
domdoc.doSomethingWithAttribute(“href”);
domdoc.doSomethingWithAttribute(“scr”);
domdoc.doSomethingWithAttribute(“action”);

Are you able to see the error?

Older posts

Newer posts