What would you expect the following to return if the property isn’t defined?
grailsApplication.config.unknownproperty
a. Returns null
b. Returns an empty string`
c. Throws an exception
d. None of the above
Answer: d. None of the above
In reality, the above situation returns an empty Groovy ConfigObject instance. If you want to know if the property exists you need to do something like:
if (grailsApplication.config.containsKey('unknownproperty')
Moving files between Git repos is easy. Just move the files from one directory to another. Delete from the first repo, add to the second.
Moving files between Git repos while preserving the Git history is not so easy. This essentially involves rewriting Git history. Fortunately the git masters created some options to support this operation.
bash-4.1$ git subtree —prefix= -b
This creates a new branch containing only the files within the subtree idenfitied by ‘dir to move’.
bash-4.1$ git pull —rebase ../repo1
Apply the branch in the original repo to the new repo. This preserves everything: paths, files, and history.
Combining git-ls and git-filter-branch, you can move a file or directory from one repo to another while changing the base directory in the target repo.
Follow the steps above to get the files into the new repo.
export TAB=$t
git filter-branch -f --index-filter 'git ls-files -s | sed -E "s%${TAB}*%${TAB}%" GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"’ HEAD`
Apply a filter-branch command from the HEAD of the current branch. Pass in the following index filter:
There are times in every Java / JVM developer’s life when you need to figure out what is happening at the log level. Maybe an issue in a 3rd party library, or maybe you’re stumped by the behavior if the logging library itself.
You can use the following JVM args to debug logging problems across all logging types:
JAVA_OPTS="-Dlog4j.debug=true -Dlogback.debug=true -Dslf4j.debug=true -Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener"
This enables debug logging for log4j, logback, and slf4j. It also outputs log change events to the console, so if you’re application is programmatically updating log levels you’ll have some idea where and when.
In C++, you can declare a variable in a derived class with the exact same name as the base class. This is allowed because each variable is properly scoped. Shadowing can lead to some fairly unpredictable behavior.
Consider a class that supports reference counting used with smart pointers (IncRef, GetRef, copy and assignment operators omitted for brevity).
class Base {
void DecRef {
m_count--;
if (!m_count) delete this;
}
int m_count;
}
Now imagine you create a derived class but also add a reference count:
class Derived : public Base {
void DecRef() {
...;
}
int m_count;
}
Derived now has two reference counts. This isn’t a problem if you don’t assign a Derived object to a Base smart pointer (assuming your smart pointers can do the type conversion automatically). Once you do this assignment, however, bad things happen. For example:
SmartPointer sp1 = new Derived(); // m_count = 1 // later... SmartPointer sp3 = sp1; // Base::m_count=1, Derived::m_count=1 // sp3 falls out of scope, Base::m_count=0, Derived::m_count=1 // Whops, Base::m_count went to zero and the original object was deleted. // Anyone using sp1 has a null pointer / deleted variable to work with instead // of a valid instance.Why would anyone add reference counting to // Derived when it is already included in Base? You wouldn’t intentionally do // this (at least I hope you wouldn’t). In this particular instance, // a sequence of small code changes lead to a brilliant runtime failure.
Base was not reference counted initially, it was an abstract class with pure virtual functions. Each derived class was responsible for deciding whether to support reference counting or not. Sometime later Base was made a concrete class with it’s own referencing counting. This change was made without going back and updating all the derived classes.
The resulting error went undetected until much later when a Derived smart pointer was assigned to a Base smart pointer; at some point the Base smart pointer fell out of scope, deleted it self, and then later an attempt was made to access the Derived smart pointer. Result: a pure virtual function assert at runtime.
With some compilers (like gcc) you can enable warnings that at least tell you when this happens. I thought we had enable this using –WAll. It turns out there’s another compiler flag for just this situation, –Wshadow that isn’t included in –Wall.
-Wshadow
Warn whenever a local variable shadows another local variable,
parameter or global variable or whenever a built-in function is
shadowed.
I haven’t found the equivalent in Visual Studio.:
I finished reading “Beautiful Code” from O’Reilly press a couple of weeks ago. (592 pages). “Beautiful Code” is a collection of essays that attempt to capture code at it’s most elegant. They subtitle being “Leading Programmers Explain How They Think”.
I never really thought of code as potentially beautiful so the title caught my attention right away. What kind of code would they present to be called beautiful? While there were some interesting ideas presented there were no bright flashes of beauty.
The subtitle was more misleading. Some of the essays did attempt to explain what the author was thinking when creating a particular design. The majority of the essays, however, skipped this interesting conceit entirely. Many of the essays could have used some insight into the programmer’s thought process because the code in and of itself wasn’t all that interesting.
I don’t want to give the impression that I didn’t like this book. On the contrary, “Beautiful Code” was a very novel approach to what can be a very dry subject. Many of the writers were able to inject a sense of purpose and passion into their discussions that was refreshing. Too many times with a book about code authors spend all their time talking esoteric coding “magic”.
The discussion on Google’s use of the MapReduce algorithm was pretty cool. The problem of efficiently searching for words found in every known searchable webpage has always fascinated me. I knew it must be a parallel algorithm. What I didn’t know was the algorithm used at Google was designed for general purpose computations. I always assumed Google wrote a special purpose system; optimized and targeted at search.
There was a topic on the design and implementation of the Linux kernel driver architecture. It was enlightening to see inheritance implemented in strict C. I knew it was possible but really hadn’t given the idea much thought. After reading this topic, however, I see a very useful and extensible design.
One topic talked about a ‘Spoonful of sewage’. The idea being you only have to introduce a little bit of garbage to ruin something completely; like a spoonful of sewage added to a barrel of wine. The theme concerned finding a bug deep in the guts of the Solaris OS. I really appreciated the insights not only into the code but the thoughts and hard learned lessons behind the code. In the end it took a very small change to introduce a very nasty and hard to debug problem into the system.
The languages used in each topic varied; from standard C++ and Java, scripting languages like Perl and Ruby, and functional languages like Lisp and Erlang. This variety of languages was refreshing and really points to the old saw about selecting the appropriate language for the job at hand.
All in all I did enjoy this book. The one problem I had with the book was consistency. The editor gave each author a lot of flexibility to discuss whatever they wanted to write about. This left some topics that were really insightful, some were light on details and heavy on ‘concepts’, while others seems simply self aggrandizing. From what I recall there were two chapters dedicated to basically the same technology. I wish each topic was more focused on the author’s thought processes and presented more lessons learned in the trenches.
You might have to pick your diamonds from the coal with this book. In the end I found “Beautiful Code” a worthy read.
I created an Oracle stored procedure the other day that used a ‘select for update’ cursor to update some information in a staging table. None of the update statements seemed to work. I thought I had the syntax wrong, etc. After spending some time just staring at the code I asked a coworker to take a quick look. We both sat down to examine my code. Everything looked fine.
My procedure looked something like:
create or update procedure my_procedure(mydata IN varchar2) is
begin
declare
cursor my_cur is select * from my_table
where my_value > 100 for update;
row_entry my_cur%ROWTYPE;
begin
-- open the cursor, fetch into row_entry, loop, etc.
-- update the MYDATA column
update my_table set MYDATA=mydata where current of my_cur;
end;
end;
This looked ok to the both of us but the MYDATA column in my_table refused to update as expected. Eventually we figured it out.
When I update the table, I’m trying to assign the value of the in parameter ‘mydata’ to the ‘MYDATA’ column of at the current location of the cursor. Note the name of both the column I’m trying to assign to and the name of the import parameter.
Oracle doesn’t recognize that the right hand side of this assignment is my input parameter. It treats the right hand side as a column name instead. So in effect I’m assigning the value found at the current cursor location for column ‘MYDATA’ to the column ‘MYDATA’ — a no-op.
Changing the name of the in parameter from ‘mydata’ to ‘p_mydata’ solved my problem. We could have saved a lot of time and frustration if Oracle had at least warned me of this situation.
One of the frustrating aspects of programming in C++ is memory management.
In Java this is, in large part, handled by the garbage collector. As long as you don’t keep references lying about that you don’t need, and the GC gets called occasionally, Java does a good job cleaning itself up. This makes memory management a little less of a hassle in Java.
When programming in C++, you don’t have as easy a time of it. The programmer is responsible for the allocation and deallocation of objects. There’s no standard garbage collector running in the background to bail you out. If you don’t delete your objects, they’ll hand around for the life of your program.
One nice standard object wrapper is the std::auto_ptr. This takes a standard object pointer and wraps it in friendlier semantics. I was trying to explain std::auto_ptr to a coworker when I found this excellent [best practices](http://www.gotw.ca/publications/using_auto_ptr_effectively.htm)%5B guide](http://www.gotw.ca/publications/using_auto_ptr_effectively.htm) to their use.
Std::auto_ptr does have limitations. You don’t want to put them in collections because they won’t behave the way you’d expect them to behave.
From C++ TPL by Stroustrup 14.4.2:
… auto_ptrs have a copy semantics that differs radically from that of ordinary pointers: When one auto_ptr is copied into another, the source no longer points to anything.
Note that auto_ptr’s destructive copy semantics means it does not meet the requirements for elements of a standard container or for standard algorithms such as sort().
The auto_ptr copy constructor changes the owership of the underlying object. If you place an auto_ptr in a container, more than likely your original reference will be deleted. When you ‘get’ an object from such a container, more than likely the object in the container will be deleted. This is all implementation-specific.
Let’s just say what the standard says – using auto_ptrs in containers results in undefined behavior. The last thing you want is undefined behavior.
Auto_ptrs are also not generic referenced-counted objects. You can add this behavior pretty easily. Out of the box, however, you don’t want to assign the same object to two different std::auto_ptrs. This results in a double delete of the underlying pointer, which is typically consider a very bad thing. Don’t do it.
Even with these limitiations, the std::auto_ptr is a very nice tool to have when programming in C++. They’re invaluable when you’re trying to figure out who owns which object and who is responsible for deleting it. Use them wisely and they can save you a lot of headaches.
So I totally geeked out this week. I spent some time installing most of the latest Linux distros under VMWare to see how the open source operating system was coming along.
I’ve dabbled with various distributions for years. I think my first install was Slackware 1.x running on a Pentium II box. The OS has made significant improvements from the early days. Installation, for the most part, was painless and quick. The window managers (both Gnome and KDE) look nice and have plenty of eye candy. Unfortunately, Linux still feels like a miss-mash of various applications cobbled together with masking tape and not a unified OS.
I installed (or tried to install) the following distributions on a VMWare server on my Athlon box:
* Ubuntu 6.10
* Debian 3.1 R5
* Gentoo 2006.1
* Fedora Core 6
* Slackware 11.0
* FreeBSD 6.2 (not Linux, but wanted to compare)Software I installed on each: Apache, Tomcat, PHP, MySQL, JDK 1.6, and NetBeans 5.5.
Executive Summary:
Quickest to get up and running: Ubuntu 6.10
Never got running at all: Slackware 11.0, Gentoo 2006.1
Most painful: Gentoo 2006.1
Most likely to use: Debian for desktops, FreeBSD for servers
Notes for each distribution:
I didn’t do any fully exhaustive tests during this roundup — I don’t have the time for such things and I was really just trying to get a feel for how Linux was coming along. Everything I’m about to write is very subjective and based on my gut reaction to each install. Your mileage will certainly vary.
Ubuntu – This was the easiest distribution to install. It was really just “insert CD, start VM” and I was up and running. By default, Ubuntu enabled way too much eye candy at first until I tuned it down a bit. (this comment applies to most of the distributions I was able to get running except Debian). The package management UI was really nice. Ubuntu feels a little removed from the hardware which is great for first time users but left me feeling like something was missing.
Debian – This is the base distro for Ubuntu so it felt very similar. Debian did enable fewer eye-candy effects by default, which was nice. It uses the same package manager as Ubuntu which works very well. Debian felt very solid, though I don’t have any empirical information to back this up. The installation of JDK 6 and netbeans was quick and painless; and NetBeans seemed more responsive. If I were to run a Linux desktop, Debian would be the distro I’d choose.
Gentoo – Biggest pain to even attempt and in the end I failed to get an install to work. Gentoo throws out all of the pre-built binaries and instead has you configure and build almost everything from scratch using a packaging tool called ’emerge’. Having built kernels from scratch in the past, I figured this wouldn’t be too bad. I read the build instructions twice before starting. I was very careful about the options and double checked everyting. In the end my newly built kernel panicked on boot. I tried again, double checking my settings a second time but ended withthe same result. Gentoo failed twice after I messed with settings for over an hour and compiled for three. This experiment was a total waste of time.
Gentoo is the distribution for control freaks and masochists. It has way too many ambiguous options to set, too many places to mess something up, and too much manual tweaking for my tastes. If I wanted to learn the totality of Linux internals or wanted total, fine grained control my kernel, this might be the one for me. As an every day user, I wouldn’t even touch this one. Yuck.
Fedora Core 6 – My first attempt with fedora failed so I went digging around the net. It turns out Fedora and VMWare don’t like each other if you configure your virtual hard disk to use the ‘BusLogic’ SCSI format. Switching to ‘LSI Logic’ solved this problem and I was quickly up and running.
The default desktop manager for FC was KDE. I used to really like KDE but this version seemed to run especially slow under VMWare. I also experienced several application crashes from KDE. If I were to run FC6 I’d switch over to Gnome. While gnome has it’s own set of problems, they seem less dramatic than those in KDE. In the end, this wasn’t a bad experience but it certainly didn’t stand out.
Slackware 11 – Slackware was the first distribution I ever used back in the day so I had high hopes for version 11. Slackware retained the ‘pick only those packages you want’ text-based installation menu system which I like. It let me avoid installing all of the typical garbage installed by default by the other installations. After I set up my partitions and selected my packages Slackware went about it’s business quickly. In the end, however, none of my three installation attempts would boot within VMWare — each time I tried to start the OS it’d just hang after post. I’m sure if I dug around long enough I could figure out what went wrong, but in the end I just want the thing to work.
FreeBSD – FreeBSD isn’t a Linux based OS but is based on the Berkeley Software Distribution (BSD) Unix-like operation system. I wanted to install this just to contrast it with the above Linux distros and ended up impressed. In terms of ease of setup, it was a good compromise between the ‘let the installer do everything’ approach of Ubuntu and the ‘get ready to compile’ hell of Gentoo. Once installation was complete it felt very familiar. It’s hard to quantify but FreeBSD feels more ‘Unixy’ than Linux. It also felt more like a unified whole than the other distributions.
Apparently FreeBSD has some excellent uptime numbers, at least according to their [wiki](http://en.wikipedia.org/wiki/FreeBSD) page. I’ve heard this from people I trust as well. If I was running a server, FreeBSD would probably be my first choice.
Conclusions:
Each distribution has it’s own set of strengths and weaknesses. Which one should you choose? It all depends on what you want to get out of your new Unix-like OS.
For me – I’m sticking with Windows for now.
Linux has definitely made some great strides over the past couple of years but it doesn’t feel ready for me to switch just yet. Can you say ‘Cut & Paste’ support? I would have thought that by now the Linux geeks would have figured out this critical UI component. The window managers have made good progress but they still fall short of a cohesive user experience.
The package managers do a fair job of abstracting all of the various package dependencies but they’re still very hit and miss. Tracking down the packages manually doesn’t seem so bad unless there are a dozen different versions and each app requires a different one. I’m wondering if Linux application writers would be better off statically linking their dependent libraries and being done with it? Why not? It still seems like most of the library versions are incompatible with previous versions anyway.
In the end OS X might be the way I go in the future. It has the nice Unix-like core with all the pretty eye candy up front. It doesn’t have the huge security holes that MS-based OSes still seem to be plagued with. Finally, the majority of applications I use every day are available on OS X. (e.g. Adobe Lightroom, Firefox, Thunderbird, and Quicken) Maybe the next iteration of Intel-based Macs will be the choice for me? Time will tell.
This post is going to deviate a little from purpose of this blog to talk a little about backing up your data. RAID (Redundant Array of Inexpensive Disks) is a set of related storage strategies that can improve performance, redundancy, or both depending on how you configure the array. These configurations are becoming more and more common in consumer PCs. These configurations lead people to think they don’t need to backup their critical data.
There is a misconception out there that a RAID 1 or RAID 5 configuration serves as a proper backup strategy. The thought is – since all my data is written to multiple different drives then I’m safe and don’t have to worry about backups. This misconception is not only wrong but getting this wrong can be downright painful.
First, some definitions:
At RAID 0, data is striped across multiple disks to improve performance. Reading data from different disks simultaneously improves performance at the expense of reliability. There is a major danger in running a RAID 0 array — if any of the disks in the array fails, the entire array fails and you’ve lost your data. Suggestion – do not run RAID 0 unless you have a specific reason to do so (e.g. video editing), and do not leave critical data on a RAID 0 array once you’re done working with it.
A RAID 1 array configuration consists of two or more disks. Each write to one disk is immediately copied to the other disks — so essentially you have n copies of each file, one on each disk in the array. The downside to this configuration is each time you write something to one disk it has to immediately be written to all other disks, degrading performance. RAID 1 costs more because you have to buy n disks for the same amount of storage.
A RAID 5 array configuration consists of n disks. Data is striped across n-1 of these disks, as in RAID 0. To avoid the reliability hit, the array writes out parity information to one of the other disks. Parity is a way to determine if the data is valid or corrupt. This sounds great – redundancy of RAID 1 with the speed of RAID 0 (well, not as fast as RAID 0 as the controller has to write the parity information) and higher capacities to boot. The downsides? It costs a lot more money to create a RAID 5 array, reconstructing the array after a drive failure can take a long time, and if more than one disk fails the entire array fails.
So if I have mirrored data, what’s the problem?
Each hard drive has a mean time between failure (MTBF) established by the manufacturer. The MTBF is a expectation on how long the drive will run without failing. Eventually every hard drive will fail, some catastrophically, taking some or all of your data with it. The MTBF gives you a sense of the drives reliability.
RAID subsystems provide a level of MTBF mitigation. (RAID 0 reduces the MTBF, meaning you’re more likely to have a catastrophic drive failure – not a good thing) A RAID 1 or 5 system simply provides redundancy in case one of the hard drive fails. This is great if a drive fails – you can rebuild a volume and you’re back in business.
What happens if your working on a critical project and you accidentally delete your entire project directory? What if you computer is infected with a virus that deletes all of your files? How will your RAID help you if you’re computer is stolen?
It won’t. A RAID subsystem will not save you in these situations — your files are gone. If you don’t have a backup of these critical files, you’re going to have to start from scratch. Ouch.
The takeaway
Don’t forget to backup your data.
You’ll want at least one copy off site just in case something really bad happens (e.g. your computer is stolen). Get in the habit of backing up your data on a regular schedule. Your schedule will depend on how often you create new information. If you’re creating critical information daily, then you should be backing up this information daily. A good incremental backup tool helps — you perform one full backup, the software tracks which files have changed since the last backup, and only has to backup those files.
Backup your data even if you’re running a RAID system. To do otherwise leaves you vulnerable to data loss.
I’ve started re-reading “Rapid Development” by Steve McConnell. This was the first project management book I read and remains the best one so far. It’s pretty hefty at 680 pages, but if you thought project-related problems could be solved in a 30 page pamphlet, think again.
McConnell writes about four factors that can influence a projects success: people, process, product, and technology. Today I’m going to write about the first:
People
It’s all been said before. People are the heart of any organization. Nice platitude, but one which doesn’t seem to stick. Even organizations that use this as a mantra seem to forget it when push comes to shove.
The people that make up your project are intimately linked to the success of the project. If you keep your people happy, they’ll be motivated to do the best work possible. They’ll take pride of ownership of the project and do what they can to make it a success. They’ll provide suggestions for improving the development process. They’ll spend their time doing their job instead of browsing monster. Happy people make for happy projects.
Keep people motivated and avoid doing things that will de-motivate them. Motivation has many faces. Different people are motivated by different things. Try to match the people on your team to the task that will motivate them the most. Give people the tools and resources they need to work optimally. Eliminate policies and procedures that exist for reasons other than improving productivity and performance. If you identify a source of de-motivation, do what you can to eliminate it.
Treating people poorly will definitely demotivate them. Running your developers into the ground might pull your butt out of the frying pan on today’s project, but what about the next project? Your top guns start leaving for better pastures. Developers with top skills know they can go out and get a better job without too much trouble. You burn them once, shame on you. They’re not about to sit around waiting for you to do it to them again. The ‘code-like-hell’ mentality will put a major drain on your talent pool.
Other sources of de-motivation?
“Do as I say, not as I do” – if you ask people to work the weekend, you better damn well show up yourself. If you come in Monday talking about how great the sailing was while everyone else was in the office working away, it’s a sign you just don’t get it. If the project is as far behind as you imply then there should be plenty of work for you. In the unlikely event you don’t have anything to work on, find out what else you can do for your team.
“Death from above” – if you tell your team the project is critical and important, make sure senior management doesn’t got about implying the project should be canceled. The last thing someone wants to hear is that senior management thinks the project they’re working is a joke. If the project can be canceled at a whim, what motivates someone have to do their best work?
“Just be happy” – with all the reports of outsourcing and exporting development jobs overseas, it’s easy to imply people should simply be happy to hold a job. Don’t do it. There is no easier way to make people feel bad about their jobs than to imply they’re disposable.
If you are going to outsource your development, don’t make those that lost their jobs train their replacements. It’s one thing to see coworkers getting fired, it’s another to see them humiliated. There is not reason to treat people this poorly, so use some common sense and show compassion.
These are just examples. I’m sure you can think of any number of additional ways you can ruin the motivation of your team.
So do what you can to keep people happy. You can’t keep everyone happy all the time, but if you put out an honest effort it will be recognized. Doing otherwise is a sure way to drive your best employees elsewhere, leaving you with a pool of average and poor performers. McConnell sites several studies that conclude top performers are up to 10x more productive than average ones. Don’t shoot yourself in the foot.
Code, Tech, Methodologies 