Don't Quit Your Day Job

My New Project

noreply@blogger.com (Chris Duesing) — Thu, 17 Mar 2011 01:26:00 +0000

Despite my recent embrace of my consulting career, as anyone who knows me would attest, I have been busily working on my own project. I have limited my consulting to 20 hours a week since the new year and have been furiously focused on refining a business plan and building a prototype. It has been a tremendous experience, made even better by the fact that I have found the perfect business cofounder. She is a former CCX coworker who I spent the better part of 4 years discussing every day how we would do it if it was our own company. Well, now we are.

I will be sharing more details soon, but for now suffice it to say that it is in the financial industry, it is written in Erlang, and I truly believe it will be industry disrupting.

Stay tuned!

Website Redesign

noreply@blogger.com (Chris Duesing) — Sat, 05 Feb 2011 07:53:00 +0000

I have officially been consulting full time (sort of) for just over 6 months now. I have some amazing clients, one of which allowed me to learn Ruby on Rails on the job. Rails has been a great success, and is quite surprisingly simple for putting together websites. I am continuing to play with Erlang in my spare time, and may be putting up a Riak cluster to serve as a distributed data store for my side project.

Getting back to the (sort of) full time comment earlier. I very much wanted to start another startup project when I left CCX, but after my experiences with the first incarnation of Simergence, I thought it best not to immediately start living on the savings I had put aside over the last 4.5 years. Though I learned a tremendous amount, the most important lesson was that a startup is just a hobby until it has traction, be that revenue, users or investment. Until I can see a clear path to a mortgage supporting company, it is not a job. With that in mind I decided to take my expertise in building software and managing projects and use it as an income source while I built my own business part time. To acknowledge my current path, I have relaunched simergence.com.

Chicago Startup Foundry

noreply@blogger.com (Chris Duesing) — Tue, 19 Oct 2010 20:34:00 +0000

This Thursday, October 21st 2010, is the grand opening of the Chicago Startup Foundry. Come by and check it out!

If you have been reading this blog for any period of time you know that in addition to a random assortment of programming issues, I spend a lot of my time focused on startups. I recently quit my day job in order to get more involved in entrepreneurship once more. I began to do some consulting with the amazing Sandbox Industries on their incubated startups, while working on my own projects on the side. I also began speaking to some people about the idea of a collective of developers and designers who could collaborate on projects and perhaps have some ideas bubble in to new ventures.

After a couple of false starts, I finally met my now partner, Griffin Caprio. Griffin is a consultant and a serial entrepreneur who runs not only the consulting company 1530 Technologies, but also works with startups as A Part-Time CTO. We both longed for an affordable, entrepreneur friendly work environment, but more importantly for a community of like minded people who could advise and mentor one another as they struggled through the same process. After several discussions and dozens of emails, the Chicago Startup Foundry was born.

As practitioners of lean, bootstrapped philosophies we are applying those ideals to this venture as well. We are subletting space from the very kind Tim Smith of Venturality. We will operate from 9am - 5pm Monday through Friday, and offer a desk and a great environment for an introductory rate of $99 a month. As we gain members, and a little cash flow, we will add services and potentially move in to a larger space. The Foundry will be what its members want it to be, through a true Customer Development process.

So we invite you to come by, check us out, and if you are interested join. You can help create a community and shape the future of the startup world right here in Chicago!

The first version of your app should be a near blank slate

noreply@blogger.com (Chris Duesing) — Fri, 08 Oct 2010 22:17:00 +0000

The difference between a fully featured app with beautiful design and a white background, black text undesigned website is the same as the difference between Avatar in 3D on IMAX and the last piece of fiction you read. If the last book you read has been turned it in to a multi-million dollar production with special effects and oscar caliber actors, choose the one before that. Now, when you picture the movie and some random book side by side in your head, which is more immersive? In which do the characters seem more alive, in which can you more clearly picture the protagonist's face? Chances are they both seem about the same to you. The reason of course is your imagination. James Cameron had to spend 12 years and invent new technologies while waiting for his buddy George Lucas to revolutionize theaters. Think about that. One movie.. 12 years... hundreds of millions of dollars... hundreds of people working full time. The author just had to describe 1% of any given scene, and your imagination filled in the rest.

The first version of your app should be a book. It should be as near a blank slate as possible, and allow the user to fill in the rest. The first piece of code you write should be that one thing that will make the user go 'aha!'. So instead of writing a laundry list of all the features your Facebook clone will have, and how each feature will be slightly different or better than the original, instead sit down and decide what is it about using Facebook that drives you nuts. One feature, and then decide how you would fix it. Then implement it. When you are done show it to anyone who will listen and get their feedback. If they don't go 'aha!' find out if your implementation is bad, or your idea is bad. You should be able to tell based on their feedback. If the idea is bad, move on. If the implementation is bad, iterate on it until everyone says 'aha!'. Congratulations, you now have a product that fills a need.

That is what your startup should be built on; a product, not an idea. Ideas are a dime a dozen, solutions are invaluable.

Erlang for Java developers presentation

noreply@blogger.com (Chris Duesing) — Fri, 23 Apr 2010 19:08:00 +0000

I gave this talk to the Chicago Erlang Users Group this past Wednesday, April 21st. It is meant to be an introduction to Erlang for someone coming from an imperative language like Java.

I am considering expanding it in to a tutorial screencast with the slides and some live coding. If that sounds interesting to anyone, let me know!

Erlang on a Mac (for the lazy)

noreply@blogger.com (Chris Duesing) — Tue, 13 Apr 2010 03:12:00 +0000

Getting Erlang installed on your Mac isn't really all that difficult. You can just download it from http://erlang.org/download.html and build from source. But if you want to plan for future lazyness, then Homebrew is the way to go. Homebrew is quickly becoming the package manager of choice for OSX, so it will not only get your Erlang installed quickly and easily, but many of your other *NIX-y tools of choice. Go here http://wiki.github.com/mxcl/homebrew/installation for download instructions. I strongly suggest reading the whole page before you start. Once you have it installed just go to the Terminal (yea you are already there if you installed Homebrew) and type 'brew install erlang'. After it completes downloading and making the source (yes Homebrew just automates the available .configure/make/make install process) you are ready for the next step.

Now that you have Erlang on your system you are going to want to get the Erlware tools. Erlware is conceptually like Homebrew, except for Erlang applications. It is a bit heavyweight and not always completely intuitive, but the benefits far outweigh the potential confusion. Once you start writing real Erlang applications, you are going to need to package and release them. While the core Erlang language is super simple, releases are arcane black magic. Having a tool that can automate the process is a real life saver. Erlware is essentially two tools, Faxien, which handles installing packages and dealing with remote repositiories, and Sinan, which will generate project structures and build your applications. You can find them at http://erlware.org, just follow the links for downloads and the Faxien universal launcher.

Once Faxien is downloaded go back in to Terminal and type python and the name of the file you downloaded. It is going to prompt you for several pieces of information, the most important is (if you used the Homebrew defaults) /usr/local/lib/erlang as the install directory. It will ask you if you want to keep your current Erlang install and install Faxien on top of it. Choose this option. Faxien will now install any application you retrieve or create with it in your Erlang distribution, making it available to any program. This will solve any dependency issues you may have otherwise run in to. Again, lazyness is key. Once Faxien is installed you can use it to install Sinan, just type 'faxien ir sinan'. ir is a shortcut for install release. All of the Faxien commands can be found with faxien help commands. ir is all you will need for now.

Once Sinan is installed it is time to do some damage. I generally use 'sinan gen' to create a project directory with all of the needed files for a valid OTP application. If the app is going to be relatively simple (99% of the time) then I generally move the contents of the project/lib/project/ directory up to the project directory. That probably didn't make much sense until you see it. For example if you did 'sinan gen' and entered 'bob' as the name of your project it is going to create a directory called bob with several subdirectories including _build and lib. Under lib you will find bob again, and inside that directory what appears to be a normal Erlang app. I just copy all of those files/directories up to the top. Sinan will handle this with grace and it feels a little less clunky. If you are planning on splitting your project in to several subprojects, don't bother doing this.

Now you can go in to the source directory, write some code, add those modules to the .app in /ebin and type 'sinan' to compile the code. After it compiles you can type 'sinan shell' which will open an erl repl with all of the proper code paths set. from here you can do an application:start(bob). And it will fire up your app and let you interact with it from the shell. Once you are happy with your code you can do a 'sinan dist' which will pack up your code in to an Erlang approved tarball format. Now Faxien comes back in to the picture. If you type 'faxien ir' it will install the tarball in to your /usr/local/lib/erlang directory.

Now, for the final piece of lazyness jackpot. When you sinan gen next, and create the project 'fred', you will be able to modify fred.app in the ebin of that project, and list bob in your modules and viola it just works as if you were using crypto or any other built in Erlang library.

Happy Erlanging!

Not a Fan Boi, but so far a Happy Switcher!

noreply@blogger.com (Chris Duesing) — Sun, 14 Feb 2010 21:52:00 +0000

I realized that all of my recent tweets have been about my new Macbook Pro (and that it is probably only a matter of time before people start to unfollow me :). I just want to assure everyone, I haven't changed, really. I know it is a little bit like joining a cult for the medical benefits, but hear me out!

I have been happily developing Java on Windows for the past decade. I got bored, branched out, and found my way to Erlang. Erlang itself ran perfectly on Windows, but between poor symlink support, cygwin weirdness and a lack of tools I realized it would be more productive to try something else. I dusted off an old desktop and updated Ubuntu on it, and was quite happy for a time. yet somehow the signals kept coming in; all of the online tutorials were on Macs, most of the other developers I worked with had Macs. I hadn't really used an Apple OS since the IIe, but my iPhone was so well designed and intuitive that I figured it was time to take the plunge. I had decided to go to Erlang Factory in March and it was time to either put Ubuntu on my old laptop or to upgrade to a new one. I went with a new one (my old laptop is 10+ lbs, and well, old).

So here I am, 5 days in to my experience and I am extremely satisfied. I put homebrew on first, and used that to install Erlang and Emacs. Then I grabbed webmachine and riak and my personal project on github. I compiled everything and after a few fits and false starts got it up and running. I installed Firefox because I am totally dependent on Xmarks. I found Smultron for html and javascript. Emacs is kind of kicking my ass because I am using it from terminal, which means no mouse! I am going to try to get used to it because it is forcing me to finally use all of the keybindings. If it doesn't work out I will try Carbon or Aqua.

So, in summary, if you are in my boat and moving from Java into a functional language with most of its tool support on *nix, consider a Mac. You don't even have to become a card carrying fan boi, I promise!

That's All I Wanted to Hear

noreply@blogger.com (Chris Duesing) — Sun, 31 Jan 2010 19:05:00 +0000

"The religious zealots who claim that good design derives automatically from TDD are just wrong. TDD is no guarantee of good design." -Uncle Bob Martin

Amen.

Erlang for Java Programmers

noreply@blogger.com (Chris Duesing) — Wed, 09 Sep 2009 04:16:00 +0000

In a previous post I declared the end of my monogamous relationship with Java. I really played the field for a little while, but it did not take long for an infatuation with Erlang to take hold. Clojure was the runner up, and something I intend to explore more soon, but two languages at a time was a bit too much.

Erlang is a functional language, but as a Java developer it did not scare me off. While the syntax is a little out there, the concepts map pretty neatly:

Immutability
I have always erred on the naughty side with Java when it comes to the use of objects. I tend to have fairly struct like domain objects with getters and setters, and leave the business logic to manager type classes. I was never comfortable tying business logic to something I read out of the db and pass around and which may have different requirements in different apps. So the switch to a functional language was pretty easy, the main difference is instead of using setters, updating an object is a bit more like a clone/set combo. It feels a little like wasting memory, but you get over it.

Conditionals vs Pattern Matching
In Java my methods tend to end up littered with if/then/else tests on the state of various objects. In Erlang the case statement is occasionally used to make sure a function did not return an error, but not much else. Instead, Erlang takes the idea of an overloaded method to a whole new level. Pattern matching is pretty easy to understand, and impossibly powerful. Each function input can be used to direct flow in to this or another version of the function. This sounds like it might lead to a bunch of copy paste, but instead it results in a few succinct versions of a function that are far easier to reason about.

Objects are Processes
One of the main reasons I picked Erlang over a more traditional functional language like Haskell is the idea of processes. I didn't quite understand how anything could happen in a side effect free, stateless world, but Erlang keeps state all neatly wrapped up inside processes. Erlang processes are instantiated functions. You heard that right, unlike in Java, where an object is an instantiated class, in Erlang you run a function in a recursive loop forever. Weird right? Well the only real trick to this is now that the loop is going infinitely, passing its own state back in to itself, it needs a way to talk to the outside world. This is accomplished through messages. By putting a receive block inside the function, it will sleep until another process sends it a message. It will then wake, handle the message, loop and go back to sleep.

There are of course many more concepts to consider, and I did not touch on OTP, but these were the main hurdles I encountered when reading my first Erlang book. I think Joe Armstrong's book is fantastic, and the new O'Reilly book is solid as well.

There is a new online tutorial for beginners:
http://learnyousomeerlang.com/

For a solid 6 part intro to OTP check out Mitchell Hashimoto's blog:
http://spawnlink.com/articles/an-introduction-to-gen_server-erlybank/

A good searchable API site (though seemingly lacking the bifs):
http://erlapi.prepor.ru/docs/

If you are in Chicago, be sure to check out our user group:
http://groups.google.com/group/ceug?hl=en

And if you are interested, my first Erlang project:
http://github.com/chrisduesing/simmoa/tree/master

Seeking an Intuitive Understanding of Math

noreply@blogger.com (Chris Duesing) — Thu, 04 Jun 2009 03:00:00 +0000

I wonder if would it help to reverse engineer how I learn? I have an efficient method for learning programming, but have been unable to transfer that over to math. What primitive concepts map one to one. What distinguishes a function from an imperative language to a functional language to math? How does one construct a mental model for induction that becomes a natural process in the way that the difference between pass by reference vs pass by value is eventually made clear. Are various notations in mathematics like programming languages and if so are they Turing complete?

So, my question to you; How did you learn math? How would you relate math concepts to programming ones? Is there some tome published that explains the why behind the how? The unifying theme that wraps it all up in a neat little bow?

Learning a New Language

noreply@blogger.com (Chris Duesing) — Wed, 20 May 2009 23:05:00 +0000

At some point I realized I was on my way to becoming the COBOL programmer of tomorrow. 10 years in to my career and I hadn't touched another language outside of Java for 9 of them (not counting a myriad of technologies used in conjunction with Java for web, XML, etc.). It really hit home at Startup Weekend when I couldn't keep pace with the Ruby programmers. Not everything was a nail, and I had become way too comfortable with my hammer. I wouldn't mind learning Ruby, but my goals did not end up pointing me in that direction. I wanted something

completely different than Java
good for concurrent, distributed and/or real-time programming

I frequent Hacker News and it is difficult not to become intrigued by Lisp after spending much time there. I started reading articles and eventually bought Paul Graham's ANSI Common Lisp. It was a good book, and I don't feel intimidated by the syntax anymore, but I have a long way to go before I intuitively can tell the difference between a function + arguments, a list and a macro body while browsing code. I am intentionally not coding much beyond hello world, because I haven't decided on a language yet, and because I want to develop a feel for the right way to do things before I just start porting over Java habits.

Lisp was my first contact with a functional language, and the entire concept intrigued me. I began to do more research and started reading up on Haskell, Erlang and Clojure. I really liked all of them, but wanted to choose just one to really deep dive in to. I picked up the Manning MEAP on Erlang and started watching Clojure screencasts. My pro and con list is still taking shape, but here is a look so far:

pro: Erlang seems like a perfect fit for writing the kinds of systems I am interested in, and has an easily understanable syntax.
con: Erlang's OTP and system libraries are a complete mystery to me and the documentation/resources are a bit scarce.
pro: Clojure lets me take advantage of Java's libraries and leverage the time I spent studying Lisp
con: The Clojure syntax isn't clicking for me, and I feel like I am not branching out far enough from Java.

I may just end up pursuing both if I cannot make a decision. I am going to step it up in the meantime. Tonight I am going to attend the Chicago Clojure Meetup, and hopefully in June I can take the Hands on Erlang training. I will keep you posted!

Startup Weekend Chicago

noreply@blogger.com (Chris Duesing) — Mon, 06 Apr 2009 03:28:00 +0000

It was a long weekend and I am completely exhausted, but it was also one of the coolest things I have done in a long time. What started with about 40 people dwindled to around 20 by Sunday, but the 6 remaining teams put together some great projects. You can find a nice summary here. I am really happy with the team I was part of. It was a great group of guys and we put together a really cool app in a short period of time. I'm looking forward to working on it some more. Check it out, its called Tweepup. I may be biased, but I think it is really useful and hopefully will get some traction.

I will probably have at least one more entry that is a post-mortem, but this is about all I had the energy for tonight.

RSS Feed

noreply@blogger.com (Chris Duesing) — Wed, 11 Mar 2009 05:09:00 +0000

I removed the old Feedburner RSS subscribe button and added Blogger's default one instead. I am not deactivating my Feedburner account or anything, but since Google seems to be planning to do just that, everyone may want to switch over.

Book Review: Private Equity as an Asset Class

noreply@blogger.com (Chris Duesing) — Wed, 11 Mar 2009 02:57:00 +0000

I recently finished the book written by Guy Fraser-Sampson. I was pleasantly surprised to find it assumed relatively little knowledge of private equity, which made the book quite accessible. There is some jargon, but it is all defined in the glossary. The author clearly has expertise in the field, and writes assuming he is speaking to someone who is thinking of investing in a VC or Buyout fund. He also covers many of the differences between the UK and US private equity markets. I was coming to the book interested in learning about the financial relationship between US VCs and startups, so the portion of the book that was applicable was somewhat diminished. I of course knew this up front, so realize that I am not holding that against the book. I will however focus on the aspects that were most meaningful to me.

The author begins by defining the field of private equity. He continues to describe what it means to invest in a private equity fund. It was interesting to learn of the J Curve, that describes how a fund collects money up front, slowly puts it in to various startups and eventually receives returns from exit events. From an investor's perspective this is starkly different than purchasing an asset that immediately begins to gain or lose value. There is a time component that makes this sort of investment behave more like a highly risky stock in a bond's clothing. He also does an excellent job of showing how a fund approach to investment is superior, as such a small percentage of startups succeed. By having a reasonably large number of startups in a fund, the investor is improving their chances of having a winner, which given typical performances will be a big one. It only takes a couple successful startups to overshadow a large number of failures.

The author covers a great deal of topics beyond the few that I have brought up. Again, it was the dynamic of a VC investing in a startup and the eventual exit that was of most interest to me. A lot of attention was given to how startups are chosen, stage of life, fund size etc. I was somewhat disappointed that there was almost no coverage of exit events. I am left extremely curious as to what the effect of subsequent investment rounds to to participants in earlier rounds. Do VCs dilute each other, are their shares the first to be sold to subsequent investors? Are exit events then limited to IPOs and buyouts?

On the whole it was a very informative and interesting book. Perhaps someday I will be extremely wealthy and reread the book for its excellent financial modeling of venture returns vs. other asset classes.

Startup Weekend

noreply@blogger.com (Chris Duesing) — Sat, 07 Mar 2009 18:39:00 +0000

I am very excited that Startup Weekend has finally come to Chicago! I recently signed up and have been trying to read up on how these things actually work. Basically a bunch of people get together for a weekend marathon session. Fri night everyone brainstorms and comes up with business ideas. Sat and Sun teams form around the various concepts and try to get the company up and running. Obviously these are going to be heavily geared towards web based companies, and in particular ones that are of limited complexity. I think it will be a really fun experience and a good way to meet some entrepreneurial minded people in Chicago. The one downside of having my own business for a year, and then 3 years as the only developer for a small company is my lack of peer networking. I will post an update after the weekend is over.

#SWCHI

Thoughts on a Development Methodology to Bridge Agile and RUP

noreply@blogger.com (Chris Duesing) — Tue, 26 Aug 2008 01:32:00 +0000

Since leaving a RUP shop several years ago I have found myself working with groups that vary between agile and no methodology. I devised a methodology that takes advantage of what exists in the agile realm, and adds some of the things that RUP addresses but agile does not. I suspect that the following ideas mostly address the problems I have encountered, rather than being general case, but I felt like sharing all the same.

I really missed a few things about RUP. Everyone was always on the same page, there was no question how much work was left and when there was a question about how things should be approached the architecture pointed the way. Agile proponents frequently argue that designing up front is an exercise in micromanaging a process that is likely to change anyway, but I always thought of architecture more as a guidepost. I also have found agile projects can turn in to runaway trains headed for a cliff when no one is planning for the long term.

I think that both methodologies drop the ball in certain places...

RUP:
1) Is far too heavy in documentation for the sake of documentation. Keeping everyone on the same page does not need to involve doubling everyone's workload.
2) Architecture and design should guide decisions and set standards rather than detailing how code will look ahead of time.

Agile:
1) Presumes that taking on each issue one at a time will produce a result comparable with thinking through the problem ahead of time.
2) Forgoes focus on risk and heads straight to implementing features.
3) Believes that test coverage is equivalent to quality.

So here is a brief outline of a gap methodology, focusing on what should be added or modified. You can use either as a starting point, though I am focusing on taking an agile process and adding some RUP best practices to it.

The life cycle is broken in to two phases, each with a few components (this may look familiar):

1) Planning
a) Establish Stakeholder's Vision
b) Architecture

2) Development
a) Requirements Gathering
b) Design
c) Implementation
d) Testing

Planning is only done once, presuming nothing fundamental in the project changes. Here stakeholder's sit down with the analyst, architect, project manager, etc roles and lay out their ideas. The project team then takes stock of the requirements and focuses on what is fundamentally required to address those needs. They set aside fine details for later, focusing on the big picture. Some candidate technologies and architectures are chosen for further review. The most risky aspects of the proposed system are identified and a prototype is created to address these.

Development begins as quickly as a particular team feels comfortable with. This will most likely be an iterative process, and the scope of each iteration will depend on the taste of the team.

Requirement gathering begins with analysts sitting down with stakeholders and getting lower level requirements. In a RUP shop this could be a business analyst and a functional counterpart defining all of the requirements up front, in an agile shop this could be a developer sitting down with a customer and creating index cards or page mock ups. This phase will happen at least once, but can be repeated for each iteration if that is preferable.

Design is a perpendicular process to the rest of development. The architect or lead developer will communicate the shape they want the software and other artifacts to take. This is a communication centric process, with only as much documentation produced as is necessary to convey these ideas. This does not need to happen in step with the rest of the process and will be heavily weighted to early iterations. This should focus particularly on any development constraints that would cause developers to not just write business logic. These might include fitting code to a particular framework, threading issues, transaction management, design patterns etc.

Development consists of taking a task list for a particular phase and implementing these tasks one at a time. The first phase will be implementing critical code or frameworks based on risk priority. Further phases will be features based on user requirements and / or bug fixes.

Testing is the combination of writing and running automated tests and QA analysts using the software to look for things that don't make sense. Quality may include not crashing, but that is not a sufficient definition. If you push 'behavior that feels natural' to acceptance testing, end users will stop coming back.

In summary, any methodology should not restrict a team or be overly burdensome. It should, however, provide enough structure to ensure important parts of the process are not being overlooked because a team does not have expertise or interest in a particular area. Technology choices, risk and general design principles can be determined early on and should be. There is no excuse for a patchwork application with redundant code and low maintainability in the name of 'requirements can change'. If you start off expecting a web based application for internal users and end up with flight control software, then wasting time on architecture wasn't going to be your problem anyway. Finally testing is important, and agile bringing automated testing to the forefront is laudable. Just don't presume it ends there.

Investing

noreply@blogger.com (Chris Duesing) — Sat, 26 Jul 2008 19:26:00 +0000

Working for a financial exchange, and developing software for it, I thought it was high time I got a lot more hands on experience with trading. I have previously managed the funds I put my 401k in, and I've picked up some stocks that I thought had long term value, but I never sat in front of a trading screen and watched the market update in real time. It has been an extremely humbling experience.

(note - This is just a recounting of personal experience. You would be an idiot to take anything I say and base investments off of it. I have no clue what I am doing. I am a software developer.)

The first thing I did was pick up a book on valuation. I found the online Edgar database and I looked at some company fundamentals in the technology sector that looked interesting. I instinctively went with these companies because I was familiar with them, their business model and the general industry landscape. So far I am compelled to stick with what I know, but the argument for diversification is hard to ignore. I watched these stocks slowly decline over a long period of time and lose me some money.

Next I decided it would be more 'trader-ish' (to make up a word) to trade a little more short term, and on indicators rather than fundamentals. This time I focused on E*Trade, because I thought they had a great product, which I was using at the time, and that the market was over-reacting to other factors. I picked it up in the low $3 range and watched it grow towards $5. In the mean time I was so excited about my brilliant 'buy stocks that have over-corrected' that I picked up some Washington Mutual as well. I watched WaMu drop from $14 to under $5 and E*Trade drop back to the low $3's. Ouch. The lesson from this was to set stop losses. Would have locked in the profits from E*Trade, and limited WaMu losses to something a little more palatable.

I then left E*Trade for ThinkorSwim to be able to trade options using a real platform. I used their PaperMoney system for a few weeks to get a better feel for moving in and out of options positions. Up to this point I had used options as a means to acquire or sell the underlying stock. I thought I would try trading on investor psychology and look for opportunities to get ahead of market reactions to news and earnings reports. I bought puts on WaMu, Ford and Wachovia just before or after earnings announcements. I was watching the tendency for the news to take a while to sink in before the underlying stock price corrected. I got it right on WaMu, but volatility stopped me out of the position multiple times. Even though I picked the right direction, the costs caused me to break even. Ford was nice to me. Wachovia did the opposite of what seemed rational to me, but I stopped out and didn't lose too much. Overall I'm up about 5% over 3 days with the latest strategy, which is hardly a long term indicator of success.

My take homes at this point are that:
1) Having real money in the market is gambling. Don't play with money you cannot afford to lose, and put stops on all of your positions.
2) I will lose more than 50% of the time, so keep the losses small and let the winners ride.
3) I have no clue what a real investment strategy is, and I am reading as much as possible from people in the field. I am extremely wary of 'how to get rich' books, and try to stick with technical ones. Alternatively, Nassim Nicholas Taleb's 'Fooled by Randomness' has been by far the best book I have read to help give me a better perspective of the market and traders. It helped me take everything else I read with a large grain of salt.

This post was purely non-technical, I will follow up in the future with more about the technologies behind trading systems as well as my experiences reading about technical analysis and financial engineering.

Seam generated UI doesn't like references to multiple entities of the same type

noreply@blogger.com (Chris Duesing) — Tue, 10 Jun 2008 20:32:00 +0000

Given two classes (minus important details like @Id, getters, setters, etc).

@Entity
public class Bar {}

@Entity
public class Foo {

  private Bar bar1;
  private Bar bar2;
}

and then running seam generate-ui on the containing project will produce something like:

@Name("barHome")
public class BarHome {}

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome;

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome.getDefinedInstance();
    if (bar2 != null) {
      getInstance().setBar2(bar2);
    }
  }
}

which of course, does not compile. Even if it did, it would not work properly. The FooEdit.xhtml page would set both instances to the same thing. This is the problem I set out to solve, not really knowing if there are any other use cases where this might be a problem.

First I Googled seam generate-ui and found this JIRA post:
http://jira.jboss.org/jira/browse/JBSEAM-994

It wasn't all that helpful, especially when I saw that Gavin wrote, "...in fact I don't see any easy way to arrive at a correct solution - this is a super-difficult one to solve by code generation, it needs human-written code." In order to achieve just that I set out to write the simplest code possible, since I evidently won't be able to modify the generator, I am going to have to re-apply my fix each time I re-generate the ui.

First thing I did was tackle what seemed to be the most obvious 2 problems. 1) this doesn't compile. 2) The bars need to be stored in 2 separate home instances. The modified code...

@Name("barHome")
@Role(name="barHome2")
public class BarHome {}

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome2;

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome2.getDefinedInstance();
    if (bar2 != null) {
      getInstance().setBar2(bar2);
    }
}

The whole thing now compiles, but the resulting FooEdit.xhtml only sets the value of bar1, no matter which is selected.

What we ultimately want to be able to do is limit changes to the components that need to know about this complexity and hide it from the ones that don't. The requirement is to not change Bar or any of the components/pages associated with it. Luckily this ended up working by making small changes to FooHome, FooEdit.xhtml and FooEdit.page.xml.

First FooHome gets a variable to note which version of BarHome it should set an id for when coming back from the BarList.xhtml page. There need to be methods to get and set the proper barHome id for this as well.

@Name("fooHome")
public class FooHome {

  @In(create = true)
  BarHome barHome;

  @In(create = true)
  BarHome barHome2;

  int selectedBarHome;

  public void setBarId(Long id){
  
    switch (selectedBarHome){
   
      case 1:
        barHome.setBarId(id);
        break;
    
      case 2:
        barHome2.setBarId(id);
    }
  }
 
  public Long getBarId(){
  
    switch (selectedBarHome){
   
      case 1:
        return barHome.getBarId();

      case 2:
        return barHome2.getBarId();
    }
    return null;
  }

  public void wire() {

    Bar bar1 = barHome.getDefinedInstance();
    if (bar1 != null) {
      getInstance().setBar1(bar1);
    }
    Bar bar2 = barHome2.getDefinedInstance();
    if (bar2 != null) {
       getInstance().setBar2(bar2);
    }
  }
}

Next the FooEdit.page.xml parameter that sets the bar instance needs to reference the new fooHome bar id instead of the barHome id . So the line


<param name="barId" 
          value="#{fooHome.barHome.barId}">

becomes


<param name="barId" 
          value="#{fooHome.barId}">

Finally the FooEdit.xhtml is changed to tell FooHome which BarHome it is going to be making changes to. Look for the s:button in the tab panel for "Select bar1" and "Select bar2". Add an action to these buttons to accomplish this. Below is the generated xhtml page only showing the buttons with the new action added.


<s:button value="Select bar1"
    view="/BarList.xhtml"
    action="#{fooHome.setSelectedBarHome(1)}" >
 <f:param name="from" value="FooEdit" />
</s:button> 
...
<s:button value="Select bar2"
    view="/BarList.xhtml"
    action="#{fooHome.setSelectedBarHome(2)}" >
 <f:param name="from" value="FooEdit" />
</s:button>

And that is pretty much it. Now when you edit a Foo, the tabs at the bottom for bar1 and bar2 will properly select different instances of bar from the bar list.

Java Library Migration

noreply@blogger.com (Chris Duesing) — Wed, 09 Jan 2008 18:24:00 +0000

I don't generally get super technical on this blog (I also don't often write on this blog, so increasing the scope couldn't hurt the frequency), but I thought I would share some of the pain I experience from time to time in migrating an existing Java project from one set of library dependencies to another. In this case I am taking the first steps in migrating an app from MyFaces JSF on Tomcat to Sun's JSF on JBoss. The pain is compounded by the fact that I use Eclipse as a development environment. Eclipse is great right up until the point you try to change one of its basic project settings, at which time you need to have a detailed understanding of all of its configuration properties. This will be a step by step how I approached the problem rather than an after the fact recipe for doing the same thing. It should be more illustrative of what a developer actually goes through in troubleshooting an issue.

Background:
The project is set up as a standard Eclipse 'Web Project'. This means it will try to control all of the dependencies for Servlet/JSTL/JSF etc as well as Java version, building and server integration. The other way of doing this is to set up every project as a generic 'Java Project' and then use Ant scripts to build everything. It takes more time to set up initially, but down the road you will end up using Ant to build for test/production scripts anyway, so the pain it can help you avoid is well worth just using it off the bat.

Step 1 : Remove the MyFaces Libraries
I deleted the MyFaces api and impl libraries from the project. I also removed them from the Tomcat launch configuration. I then added the Sun RI version which can be downloaded directly from dev.java.net. Upon republishing and relaunching Tomcat I got the following error:


SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String;
at com.sun.faces.config.ConfigureListener.getServletContextIdentifier(ConfigureListener.java:1804)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:558)

Several Google searches imply this problem falls in to one of a few areas:

I have previously upgraded Tomcat to version 6 and there might be a dependency somewhere on the old version of the servelt implementation that does not implement the latest spec.
A previous upgrade of Java to version 6 may be causing an issue with the way jsf/servlets loads classes that is incompatible.
The latest JSF libraries have different dependencies than MyFaces did and there is a clash.

Step 2: Troubleshooting based on shoddy information.
I initially try updating to the latest versions of the JSF libraries from dev.java.net to no avail. I then try pulling jstl from the latest Glassfish. I look around for newer versions of the servlet impl, but I have the latest version of Tomcat so that seems unlikely to help. To eliminate Tomcat from the equation I plop the war file in JBoss and get the same exception. Has to be the project itself or somehow still Java6. The Java version seems a strange solution as the app worked before pulling the MyFaces library. I set up a new Tomcat server in Eclipse with Java 5 runtime and the same error occurs. This has to be a library incompatibility issue of some sort, but Java doesn't help in this area so the experimentation continues.

Step 3: Getting the latest version of all dependencies.
I find a page that explains the steps for getting JSF running in Tomcat, its dated, but it sparks an idea... why not start over? So I merrily delete Tomcat and all of the jars my project is dependent on. I remove that Tomcat from the Eclipse servers list and then go in to the project. Uht oh, now I notice that my project compiler level was building to 5 and I was trying to deploy to a 6 runtime.. was that the source of the problem? May be hard to say even if this fixes the problem since I blew away so much. This is a great reminder of why the patient, one step at a time approach is always the right one, even when frustration sets in.

Step 4: Denouement
Once I get the latest versions of the libraries dropped in to the tomcat/common/lib folder and the project and server pointed to them I need to go through each entry in the project 'properties' menu and make sure everything is up to date and consistent. Once this is done the project builds and deploys nicely.

This is one of many instances where you come to realize that the more a tool works to make your life easier, as soon as something goes wrong you really need an intricate understanding of it. The more the complexity is hidden from you on a day to day basis the worse it is when you finally peek under the hood. It never hurts to have a general understanding of how the tools you use work, but it really is times like these that make it happen. Good thing they don't happen every day...

Limited Domain Knowledge

noreply@blogger.com (Chris Duesing) — Mon, 26 Nov 2007 17:43:00 +0000

Michael Feathers over at Oreilly's Beautiful Code blog just wrote a post about the influence of an organization's structure on the software they develop. It almost seems too obvious to consider, but the ramifications are enormous. One of the difficulties I face in my current job is that this is my first role in the financial industry, so my perspective on the domain of markets is obviously limited. I have been trying to develop an SOA foundation for integrating our current applications, and to make future development more efficient and effective. One of the first things I needed to do was to design a domain model. I did this as a set of interfaces that define markets, products, orders, trades etc. I chose interfaces specifically because to integrate already existing applications with specific domain models, it is easier to add an interface rather than rip out an existing class hierarchy. With that in place I started designing services that would allow these applications to make themselves available as services. In the end I will have a robust and loosely coupled system that will make development cleaner and easier. The only problem is, what if I made a mistake in the domain model? That is the sort of problem that could cause a catastrophic ripple effect down the road. Presuming we don't integrate with anyone new, or launch a product that doesn't work differently than our current ones there will never be an issue. But how do you protect yourself from this kind of thing?

Whats so great about a startup?

noreply@blogger.com (Chris Duesing) — Tue, 25 Sep 2007 21:04:00 +0000

I sometimes find myself trying to explain why I did not go back to a corporate job after my startup wasn't successful. It is easy to point the finger at bureaucracy or say that I have more input at a small company, both of which are true. But as Jeff Yee over at Redfin points out, where else are you going to learn how to start a business? I always have big ideas for my next job (Start a MMO middleware company or become an architect at a trading firm) but it would probably be smart to take on a bigger role at a smaller company first. Maybe I'll find a way to help start a trading platform company as a chief technologist or some such thing. Of course I have a million things I want to accomplish here first. Only time can tell.

P.S. A big congrats to my friend Bryan for doing exactly this with his new project Epicenter Studios

Design Sense

noreply@blogger.com (Chris Duesing) — Thu, 09 Aug 2007 19:52:00 +0000

I was reading the Beautiful Code blog and came across an entry on Design Sense. I could relate, in that I feel like I 'get' when something is programmed to work simply, elegantly and in a maintainable fashion. Not every line of code I write falls in to that category by any means, but it is a subconscious litmus test I am constantly performing. Writing a large application that reflects these ideas requires a large degree of up front thought. It is hard to keep in mind all of the conflicting needs an application will have. That is why I think Agile is useless on anything but a small project or using a preexisting framework that already fits the bill. I also am surprised there is not more of a critic community out there in the blogosphere that rates open source projects on their design and architecture, like art critics do in the real world.

MMOL (L is for Learining)

noreply@blogger.com (Chris Duesing) — Wed, 25 Jul 2007 22:34:00 +0000

It looks like someone got in to the MMO space for education. Grockit, was originally supposed to be online gmat classes, has now announced they are going to create an MMOL. Details are sparse at this point but the project is interesting. They have 2 job postings for a Ruby on Rails and a HTML/CSS coder. I can only speculate that means they are planning on making it web based, rather than a classic 3D thick client. Can't wait to see where this goes!

PPROgramming - Part 3 : Levels and Advancement

noreply@blogger.com (Chris Duesing) — Tue, 10 Apr 2007 18:11:00 +0000

Leveling in MMOs is where psychology meets mathematics. It is such a simple concept, easy to program and largely responsible for the addictive nature of these games. Levels provide goals, and with small enough milestones and interesting rewards it can be difficult to put a game aside. Real life has the same concepts of advancement at work (or school) and new skills that require a solid foundation in the ones that came before it. However, real life can be messy and non deterministic which can lead to apathy and boredom. So it is time to take the lessons learned from MMOs and apply them to the real world.

PPROgramming must incorporate an advancement system that is flexible enough to allow for multiple paths to the same goals, yet be well enough defined to be codified. In order to add levels to the system a mechanism must be added to quantify progress. Games typically use experience points that can be obtained through killing monsters and completing quests. Several options exist to parallel these concepts including projects, applications, courses, certifications etc. When a new level is reached in a game a new skill is typically given as a reward, however in real life the new skill is obtained over time as part of advancement. Gaining a skill can be broken in to two phases; learning and application. The learning phase can be accomplished by reading a book, looking at source code, talking to people or taking a class. The application phase will generally require writing code. As measuring the learning phase is difficult, if not impossible, it should be successful completion of the application phase that is the milestone and measurement for advancement.

Part 4 of the series will cover putting all of these concepts together and a suggestion of a simple implementation of the system.

PPROgramming - Part 2 : Classes and Skills

noreply@blogger.com (Chris Duesing) — Wed, 07 Mar 2007 00:06:00 +0000

When designing a MMO several design decisions must be made early in the process. Wether to go with system that is skill based or class based. Does the game have xp and levels? There are of course hybrid models, and probably models based on different principles, but for any given game these are the concepts that define advancement. These concepts will shape the discussion of any other part of the game. Therefore to design a PPROgramming game, a similar set of rules must be determined up front. In programming there are programming languages and there are concepts that transcend language, say client/server, multi threadding, OO design. Languages have an obvious impact on how, and even if, these concepts can be utilized by a programmer. Similarly in a MMO all players have a similar set of goals, quests etc. What differentiates how each player can solve these goals depends on the class they chose.

So without further comparison, which would likely result in conceptual mismatches, let's just go ahead and equate classes in a MMO with programming languages in our PPROgramming game. By default this leaves us with comparing technolgies/concepts with game skills, which I think will fit very nicely. Next time we will cover advancement.