Coding

Fun with “expect”

»Posted by on Mar 27, 2012 in Blog, Coding, Systems Administration, Technology thoughts, Utilities | 0 comments

Fun with “expect”

A few years ago, I had call to automate some file transfers from one system to another. However, for security purposes, FTP was not an option. (It probably shouldn’t ever be on production systems–throw up a VM for that so when A Bad Thing happens, you can easily reconstitute that point of entry).It was at that point that I discovered the handy Tcl-based *nix utility expect. expect is nothing more than a simple call/response program, but oh, the places you can go. For instance, here’s a simple script that grabs backup files from one server and transfers them to the backup_archives directory on the local server. This example uses password authentication, but if you use keys, just add the -i /path/to/key.pem line in the scp spawn...

read more

A few final thoughts on legibility

»Posted by on Oct 16, 2009 in Blog, Coding, Technology thoughts | 0 comments

A few final thoughts on legibility

This is closely related to the post on code formatting.Code can be readable, but still not easily understood. Maybe it reads well but is misleading. Maybe you took the time to pick a good name for that variable, but the way it’s used and what it means has changed, but the name hasn’t. That’s worse than using a cryptic name; at least in the latter case, the reader knows the name is meaningless. If the name is misleading, the reader can make ungrounded assumptions about what’s happening in the code, leading to misunderstanding, and eventually bugs. Also, tragedy.As I conclude this mini-treatise on a few best practices I hold dear, the overarching theme is simple common sense. As developers, we all too often assume a priori that the only person that will ever...

read more

Duplication in your code. Also, duplication. And duplication.

»Posted by on Sep 24, 2009 in Blog, Coding, Technology thoughts | 0 comments

Duplication in your code.  Also, duplication.  And duplication.

From the department of redundancy department, IT coder division: Duplication is probably the single, most important thing to banish from your code. Duplication can take several forms:   textual This is the simplest and often the easiest to find. This is when you have sections of code that are identical or nearly so. This is often a result of copy & paste programming. Several techniques can be used to eliminate it, including: extracting methods and reusing them, making a method into a template method, pulling it up into a superclass, and providing the variations in subclasses, and other basic refactorings. See Fowler’s “Refactoring” for more detail. functional This is a special case of textual duplication and is present when you have multiple...

read more

Pretty framework, same old code

»Posted by on Aug 22, 2009 in Blog, Coding, Technology thoughts | 0 comments

Pretty framework, same old code

Are you a fad-follower?  Do you always use the latest new development environment simply because it’s this year’s model?  Here’s my axiom: Application architecture is less than optimum if it dogmatically conforms to a trendy framework at the cost of following good design/implementation practices. For example, is it correct to be inflexible and use private fields and getters/setters for a simple data structure (e.g. a DTO)? If a field is transparently readable and writable why not simply make the field public? In most languages you can do that. Granted, in some you can’t. For example, traditionally in Smalltalk all fields are private and all methods are public.In general it’s a good thing whenever you can throw out, or avoid writing, some...

read more

Code formatting

»Posted by on Aug 18, 2009 in Blog, Coding, Technology thoughts | 0 comments

Code formatting

Code should be easy to read. Code should be convenient to read, not convenient to write. There are several things involved here. Choosing good names that are self-explanatory is a good place to start. Strive for simple solutions, even if they are more verbose or inefficient. Whether inefficiency is a problem won’t be known until profiling is done later in the project, in a real production situation. Choose style and formatting conventions early in the project, and conform to them. Require that everyone conform to them. This will be easier to do if everyone has a hand in deciding on the conventions and buys into them. This will make the code uniform and thus easier to read. And get rid of any and all duplication. Do you format your code?  Your queries?  Using...

read more

Functional specs? Anybody? Bueller?

»Posted by on Aug 14, 2009 in Blog, Coding, Technology thoughts | 0 comments

Functional specs?  Anybody? Bueller?

 OK, so you decide to add tests to your code. That typically isn’t so easy. The odds are that your code wasn’t designed and/or implemented to be easily testable. That means you will have to make changes to it to make it testable without breaking any of it (this is usually called refactoring these days). But how can you quickly and easily tell if you’ve broken anything without that comprehensive set of fine-grained tests? Tricky. It’s even trickier than that. If you take the approach that you’ll write tests for all your code after you write the code, you have to go to extra effort to try and design/write the code to be testable.Maintaining an adequate level of testing when writing tests after the code being tested takes time and planning. And if you have...

read more