To understand why this is might cause problems, Imagine a local theater is putting on a special showing of blockbuster moving starting at 2:00 am on November 6th. If I were to show up at 1:59 and my friend ; who was supposed to meet me there — showed up at 2:59, one of us would miss the special showing, Even though technically we are both on time.

Most systems that care about this kinda of stuff handle the ambiguous hour by designating one them with the a different offset. So if we are in Texas on Nov 6th, the 2:00 AM hour would be 2:00 AM CDT(Central Daylight savings Time ; -7 UTC), and the second hour would be 2:00 AM CST (Central Standard Time ; -6 UTC). Unfortunately most systems grab the localtime from the system when preforming datetime calculations; most of the year this works just fine; until the first Sunday in November.

Consider the following python code

import datetime
import pytz
tzinfo = pytz.timezone("America/Chicago")
date_time = datetime.datetime(2011,11,06,2,0,0, tzinfo=tzinfo)
print date_time.strftime('%Y-%m-%d %H:%M:%S %Z%z')
print date_time + datetime.timedelta(hours=-1)

Output:

2011-11-06 02:00:00 CST-0600
2011-11-06 01:00:00-06:00

pytz assumes Standard Time, but when we ask the timedelta for the previous hour, we get an incorrect result, It should have reported the time as 2011-11-06 01:00:00 CDT -07:00, but instead throws away the time zone information during the calculation. If we do this calculation in UTC then convert to localtime we get the correct result. The only problem for programmers is figuring out when the DST transition occurs. Even using the excellent pztz library relies on the programmer to tell it when the calculation result should be in DST.

My solution to this problem in python was to parse the olsen database and figure out the DST transition times then pass the dst flag to pytz when converting to localtime

Note: This is a well understood limitation in python, Search http://docs.python.org/library/datetime.html for the keyword ‘ambiguities’. See also http://pytz.sourceforge.net/

Large companies that have this mentality forget their greatest asset is the people and the creativity they employ to get their jobs done. A Company with an empowered workforce that has access to a large palette of tools and good processes is able to shift with the ever-changing tide of technology. Contrast that to a company that spends years perfecting their ridged toolset and standards; you quickly realize change is almost impossible.

Great developers (and I believe great people) will naturally gravitate to great tools and will insist upon them. (See http://www.paulgraham.com/gh.html). This being the case, tool selection is an exercise left to the team but process is the realm of governance. For software developers, If the process is to run a script with a specified install directory to install an application, I as the user care not what language or framework the script utilized, but that it conforms to the install process.

This illustrates why I think isolation testing with mocks can lead to a misplaced sense of code coverage. Lets look at some code so I can explain.

Consider the following

RequestContext target = mock(RequestContext.class);
when(target.getParameterNames().thenReturn( new String[]{ "marker" } ));
when(target.getBaseUri()).thenReturn(new IRI("http://localhost:8080/atom"));
when(target.getTargetPath()).thenReturn("/foo/bar?marker=1");

Since we don’t have access to a real RequestContext() it makes sense to mock this out. Its only when we actually deploy our application do we realize the subtle errors here.

The actual call to

target.getBaseUri()

returns

http://localhost:8080/atom/

instead of

http://localhost:8080/atom

In addition, this bit of code

target.getTargetPath()

returns

"/foo/bar?marker=1"

instead of

"/foo/bar”

Both of these issue are impossible to detect without actually running your code with a real request that returns a real RequestContext().

This illustrates the biggest downside to using mocks for isolation testing, or even isolation testing as a general rule. When you isolate a test with mocks your almost guaranteed your classes are going to pass the unit tests because you are in complete control of the inputs your class is subjected too. In a real world application this is simply not true.

One of the great benefits to code testing is to validate the class works within a certain context. By separating your classes from the context they will run in; you completely negate a huge benefit to code testing.

The need for functional tests
In contrast to isolated unit tests, functional tests exercise your code with a real world context.

Functional tests have the following benefits

1. Broader strokes of code coverage
2. Tracing errors with a debugger can be much faster than sorting through unit tests guessing what part of the system is acting up, and tweaking unit tests
3. Users can submit inputs that cause the error, which can and should be easily turned into a functional test.
4. Confidence your application delivers the service it was designed to provide. The user — and by extension you — don’t care if all the classes work as expected in an isolated environment. They do care if your application provides the functionality promised.

Don’t get me wrong I’m not anti mock. I just don’t subscribe to the notation that EVERY class must have an isolation test. Using a mock – like any good tool — at the right time and for the right purpose is important. Many of the classes we write are better served in a functional test. We still get the same code coverage, and the test is more accurate and less fragile.

I think it was apparent to any one who attended Google IO 2010 that google was really pushing the idea of the browser as a platform. This is a different take on the browser than most of the developers I have daily interaction with. Most of the developers I know don’t want the browser to be the platform of the future mainly because of the browser compatibility issues. First its the “Works in Firefox but not in Internet Explorer” then there are the performance issues, network and JavaScript based and I’ve heard more of my fair share of DOM hate . Having worked with the browser most developers are left with a very sour taste in their mouth and groan loudly when ever some one states “The browser is the platform of the future!”

So why is Google betting on the browser? Even at a time when most couldn’t imagine the browser providing a truly interactive experience Google Maps made its debut and changed everything. But Google has a problem, The browser as a platform can be a very hostile development environment. So it’s no surprise Google IO 2010 sessions were flooded with ways to make rich client side applications on the browser simple and less hostile. Google’s prize fighter in this effort is GWT. The GWT compiler abstracts away the browser specific issues improves the performance of the client side application and encourages code reuse between client and server. GWT attempts to allow developers focus on the application experience without all the browser specific worries that are usually associated with complex rich browser applications.

This shift from avoiding client side development to adopting it as the primary development strategy has some interesting consequences. First is the movement of the presentation layer from the server side to the client side. Because of this, the HTML template engine is no longer be useful to modern browser developers. Also, Ajax moves from being a cute way of creating the appearance of an interactive application to the primary way an application retrieves data from the web head. In this new paradigm the web head becomes what is essentially an RPC service. To any one that is paying attention this shift has huge implications for web frameworks like ruby on rails, that have built their framework around server side templates and easy creation of restful web services. What this means is that the bulk of the application is no longer on the server side, but on the client side. This is a big win for scalability as the web head has less to keep track of and is freed to be more stateless, which is just what you want if you want to scale your web application to millions of users.

One last thing this paradigm shift means; SOA gains much more relevance in the web application space. A rich client consuming web services is a match made in heaven for SOA architects. So what does this have to do with the cloud? Well as it turns out, SOA and the Cloud have a great relationship together. And here I’m mostly speaking about PaaS ( Platform as a service ).

So lets talk about Paas. In the cloud space PaaS is probably the most under estimated and un-interesting to most early adopters of cloud. Most major customers of cloud services are more interested in figuring out how their current software platforms can utilize the cloud than develop applications targeting the cloud platform. The fear for cloud adopters is of vendor lock-in. If you develop applications for Google App engine then you decide you want to use some other cloud vendor, your stuck. You have developed your application for Google’s PaaS; and it’s not exactly transferable to other cloud vendors or for that matter on premise. This issue alone is the biggest detractor to PaaS. Cloud vendors are just not seeing a lot of traction in the PaaS space, and I think this is the primary reason.

What we need is a PaaS independent platform developers can target which will work no matter what cloud vendor you choose. Funny thing is, this problem has already been solved in the Java world. It’s referred to as J2EE and it’s associated standards. The idea is that you develop your Java application targeting these Java standards and in theory, your application should run on any stack that supports these standards. So I could develop an application on a Tomcat/JBoss stack, then deploy to an IBM or SUN stack and the application should run just fine.

The Good news is Google recognizes the PaaS issue and is hoping to capitalize on the success of the Java standards in the cloud. In the Google IO 2010 Key note they announced a partnership with VMware to deliver an open development platform that all cloud vendors could implement and allow developers to target a vendor neutral PaaS.

This could be huge, as this vendor neutral development platform could bring more companies to the cloud and truly change the way we look at hardware from a development standpoint. No longer are we worried about how our application will scale within the hardware infrastructure. Developers will be free to focus on the client side user experiences and web services on the server side should just scale as needed thanks to the cloud. One button deployment to a production system can truly be a reality lifting a huge burden off change and release and developers in general.

How PaaS could do this may be the subject of a future post. But for now, I think its safe to say PaaS has a big future ahead of it.

A lot of the code in the real world is spaghetti code, and this is probably not going to change soon. For programs that would have ended up as spaghetti anyway, the object-oriented model is good; they will at least be structured spaghetti. But for programs that might otherwise have avoided this fate, object oriented abstractions could be more dangerous than useful.

– Paul Graham “ANSI Common Lisp”

Objects encapsulate state, like a User class might encapsulate the user name and password of a user. Processes act upon that state, processes shouldn’t create more state, but only manage the state that is required of the program.

Processes can be expressed best in a functional programming style, however state can not. State can be managed best by encapsulation into objects, Processes do not benefit from encapsulation.

Think of functions as Processes, they usually act upon data with an input and output that needs to be stored somewhere as state, think of objects as the storage of that state.Once we clearly define these relationships, its easy to see a utopia of the 2 concepts is a mix of Object encapsulation for data and state, and functional programming style for the methods that act upon the objects.There are many contenders, but I’m not quite sure any of the languages today offer this perfect mix of objects and functional mix.

In absence of this perfect mix, my goal as a software engineer is to write software in a functional way while at the same time reducing state within the methods and ensuring my methods act only upon the state that is within the object its attached to. Once you start using methods from one object to act upon the state of another object, you might as well not have object encapsulation at all and place the state into global space, as the entire reason you created the objects was to manage the state by using only the methods attached to that object.

This leads to a startling conclusion some might find controversial, Getters and Setters are evil, If you ever think you just cant live without a getter or setter, you may need to rethink your design.

2. Your keyboard matters, Good typing habits matter.

3. Be balanced, don’t believe everything you hear or read, including this. Come to your own conclusions, know that nothing is ever black and white. Don’t dismiss the bad ideas, and don’t trust the good ideas.

4. Process can be a “good thing” ( Agile, Extreme, Scrum, etc.. ) But it doesn’t make or break your project. People make or break your project.

5. Don’t choose a language based on how fast it is but instead, how fast you can develop with it.

6. Don’t choose a language because there is a large pool of developers familiar with that language. The larger the pool of developers the more likely you will be temped by a fancy resume and hire a mediocre programmer. However if you dip into a smaller pool of developers you know the developers in the smaller pool are there, not because it will look good on their resume, but because they enjoy working in the language. This increases the chance you will get a star programmer.

7. The programmer is greater than the language. This means you can give any language to a great programmer and you will get great code. The opposite is not true, you can’t give a great language to a mediocre programmer and expect great code.

8. Your Language matters. Giving the right language to the right programmer can have a huge impact on the success of your project.

9. Not all languages are created equal. Some languages are more powerful than others. The problem is not with the languages, but the people that use them. If we see a language that is less powerful than our favorite language X, we know it’s less powerful because is doesn’t have feature Y. But if we see a language that is more powerful we don’t recognize it as more powerful. We just see a language with some strange syntax and some extra cruft added on. We reckon that it’s just as powerful as our language X, but nothing more.

This is partly because we are creatures of habit, but mostly because we have trained our brains to *think* in our language of choice. People don’t think in terms of feature Y if their language doesn’t support it. hence its not necessary nor needed. This means you could stumble upon the language equivalent of a super weapon, but never know it.

10. Don’t think your so special. Don’t get me wrong, every one needs to think they are special, but programmers take it to the next level. It’s not enough for us to think we are special, we have to display that individuality in the programs we write. Hence we write tools tailored to only our special needs and tend to write our programs in a style that is uniquely ours.

This is the central idea behind Perl, although most people don’t know it. Perl allows the programmer to write their code and tools in the most beautiful or bizarre fashion. This only fuels the idea that we are special because we wrote this thing in such a way as only we easily comprehend it. We create these incredibly complex 1 liners or beautifully efficient terse code and we pat ourselves on the back for creating this code that takes any other programmer 20+ minutes to comprehend, We are proud of this because it means we are special and more intelligent than the other guy. Because we *get it* and they don’t.

Although this allows us to show off our individuality and show how clever we can be. It makes collaboration difficult if the other programmer gets a head ache deciphering our code. In the end, he won’t want to work with us, and will routinely suggest the code should be re-written. Sometimes even naming conventions such as CamelCase or under_score will cause other programmers to request a re-factor. Because it doesn’t match the style which defines their individuality. Which leads me into Number 11.

11. Never stop learning. Once you stop learning you die. Seriously… Programmers are like trees. Trees are always growing, they never stop. If a tree stops growing it dies, becomes stiff, brittle and collapses. Programmers are the same, once you reach a point where there are no new ideas that can effect you and your programmer experience. ( AKA you know it all, been there done that ) you become stiff and un-movable. You become the guy no one wants to work with, the OLD guy set in his ways with no room for improvement. Avoid these people at all cost, their poor attitude is infectious.

12. Sleep. There is a myth among programmers that the guy who pulls the all nighter is the programmer equivalent of a bad ass. In the short term you may make significant progress in a 24 hour span, but that is not going to make up for the productivity you will lose recovering from sleep deprivation during the next few days and weeks. A good night sleep is good for your brain and your arteries, especially as you get older.

13. Do something else besides program. Preforming other activities besides programming exercise different sections of the brain. This not only makes you a more rounded individual but also a better programmer.

The truth is, and I came to this conclusion only thru experience; there is no Vudo. The effect does in fact have a cause. You only have to follow the effect to it’s logical source now matter in-conceivable the cause could be, it does have a cause; you have only to find it.

The skill you gain from this experience is the ability to diagnose that cause sooner than the guy next to you.

Wow… I’m getting old.

< brian > hey, please make sure to turn on updatedb in your build script. < thrawn01 > should be on by default, but I'll check.** I sent some messages confirming its on as default on the new boxes **

< brian > life is filled with mystery< thrawn01 > That is just a nice way of saying u were mistaken< brian > so, your theory is that someone went to           prod4 and sat-svn1 and turned it off?< thrawn01 > ninjas< brian > stealthy root ninjas. very likely.< thrawn01 > indeed.

I also found a qoute from stephen hawking

"The whole history of science has been the gradual realization that events do not happen in an arbitrary manner, but that they reflect a certain underlying order, which may or may not be divinely inspired"

I find that I would have to agree.

To get a list of all the C++ symbols in a dynamic library use ‘nm’ command. You can get a demangled listing of the symbols by using ‘nm –demangle’

Output
symbol types: each symbol type is shown by a letter. If the letter is lowercase, the symbol is local. If the letter is uppercase, the symbol is global ( external )

nm- lists symbols from object files for each symbol the following is displayed:

• the value in hexadecimal
• the symbol type
• the symbol name