an afternoon I'll never get back, thanks Eclipse!

Spent Friday afternoon fighting with Eclipse. Around lunchtime, my development environment stopped working... When launched from Eclipse the app couldn't find the log4j, Spring, or Hibernate config files. After many false starts and much gnashing of teeth, finally noticed it wasn't all config files that weren't getting copied into the projects' output folders but only .xml files.

Finally managed the right phrase in Google that found me the answer: http://dev.eclipse.org/newslists/news.eclipse.platform/msg74562.html

Apparently, Eclipse plugins may update one of the preferences that tells the builders which file extensions it shouldn't copy to the build output path. To fix it, you have to go to 'Preferences... -> Java -> Compiler -> Building' and then check all the extensions entered into the Filtered Resources text field.

I'm not sure if it was a plugin change, or (probably more likely) changes I was making to my launch configurations to not run out of the 'dist' directory into which the inter-project Ant build packages everything.

I'm not sure if I should be happy that the offshore team I've now inherited at least got the Ant build right. Or, if I should be concerned about whether they've actually been running the code / configuration they think they are when running under Eclipse.

One more in a long line of complaints I've had regarding how this set of applications is configured. Normally, I'm the one on whatever-team-I'm-on pushing for extensive runtime configurability. I don't know why this project's configuration setup -- not the Spring/Hibernate, the home-grown .properties file reading and command-line handling stuff -- rubs me the wrong way. The nonsensical or nonexistent documentation, the obfuscated search paths, the unhelpful error messages, or the fragility of the whole system when you're missing one piece... all of the above?


Even with that lost afternoon, I still love Eclipse. After all, it's free. Oooh, free. One plugin that now I can't live without: Remote System Explorer.

I've got to run Windows at work, and the corporation-approved SSH client sucks balls. When you resize a terminal window... what would you expect to happen? More columns/rows? Bah! That's too obvious and old-school for Attachmate Reflection's SSH client-- instead the mother f*&#$*#&er resizes the font. Badly.

PuTTY is mediocre. The corporation's security agent can't be disabled, and it prevents the cygwin install from running completely.

Enter Remote System Explorer. Multiple terminal windows. Does the 'right' thing when resizing or scrolling. Gives me a file-tree view of the remote system via SFTP. I can edit remote files within Eclipse and it automagically saves them to the remote system.

Eclipse is a beast, and a bit of overkill for a shell window. But, I've already got it open. And, unlike my Ubuntu system running under VMWare... I don't feel like the corporation's jackbooted thugs will re-educate me if/when they find I'm using it.

conclusions

• If you write an application where the order of command-line options matter, you're a bad person.
• I need to use the adjective 'Diabolical' more often.
  

so many resignations, none of them mine.

Two friends at current employer resigned. Unfortunately, they were both awesome engineers, so the future looks bleak. The only silver lining is there will be less competition for the 'good' projects. I was looking forward to working with them and learning from them.

One friend at old employer resigned. Finally. Sucks for those that are left behind, but it's a great move for him.

As for me, I'm still trying to decide how long to stick it out at the current employer. Finally feel like I'm getting the hang of my current project. We're continuing to refine our processes, and we've got two new engineers that seem to be very good. Now that I've settled into the rut, I've been knocked out of it to take over as tech lead for one of the people that's leaving. More responsibility, higher profile, more interesting work... I should want that right? And not the cozy rut?

In less wishy-washy-I-am-lame news, things I'm enjoying:

• Dexter
• Dr. Horrible
  
• 'A Fire Upon the Deep' by Vernor Vinge. I couldn't put it down. Read until 4am night before last, and 2am last night. Very good.

I bought Toll of the Hounds a month ago (delivered right after the return from vacation). Decided I'd re-read the Malazan series from the beginning before starting on the new book. Again. I'm amazed that it's holding together on the third read through. Picking up nuances and hints I'd completely missed before. And this is the third read through. I've made it through book four, and decided to read 'A Fire Upon the Deep' as a palate cleanser.

another sign of the apocalypse

I was struck speechless while perusing the beer at the supermarket yesterday.

Bud & Clamato == Chelada?

It's not quite intriguing enough to want to try myself. But, inflicted upon someone else... Perhaps a six pack as a house warming gift for my enemies

don't eat the chicken pizza

Back from a week in Cancun! Luckily, we only got horribly sick on the last day. Just in time to fly home. Awesome.

We stayed at the Dreams Tulum Resort. For an all-inclusive, it was reasonably priced, and very nice. The staff was awesome. The food at the resort's restaurants was all very good.

The majority of the week was spent listening to downloads of the Geek Show Podcast, sipping mojitos, and staring at the ocean.

Thursday, we took a tour to Chichen Itza. Oh lord... it was a long drive from Tulum. But, the ruins were worth it. Very interesting, it was great to see the scale of things. Unfortunately, climbing the steps is now verboten.

Included in the tour package was a lunch at the buffet at the Mayaland hotel right next to the ruins. It looked risky, but we were lulled into complacency by the luck we had with our resort's food. All four of us got sick that night and the next day.

On the way back from Chichen Itza, we stopped at an amazing cenote. We only had a half hour, so we decided not to take a dip.

further lessons in patience

I've been tracking down why a run of the rules engine on the Windows platform produced different results for a particular bill was different from Unix.

After debugging the problem, I tell the business peeps the same thing the other 2 developers have been saying for the past month:

• I can't reproduce that unexpected behavior on Windows or Unix, using my builds or the official release builds.
  
• Also like the other 2 devs, I tell them there's a bug in the code we need to fix. The unexpected behavior is actually the desired behavior and fixing the bug will result in the desired results all the time.

Through pure chance... I realize the order in which bills work their way through the system will affect the outcome of the regression test. If bill A is part of a claim X, and claim X has one or more bills that haven't yet been reprocessed at the time bill A is pulled out of the FIFO bill processing queue... when the rules engine queries the database for the bills that are part of claim X, the engine won't retrieve the yet-to-be-processed bills.

This fits a big symptom of our inconsistent results for this and other bills. We see an unexpected result, and we try to reproduce it after-the-fact... no luck.

I can finally reproduce the original problem, but only if I run the regression test prep scripts, and then manually process a handful of bills from the claim and leave some stuck in limbo.

I naively ask the person that runs the test suite, "I think I found the problem, but to confirm I need to look at the log files from the regression test run on Windows. Do we still have the logs?"

I'm told, "I don't know, I don't think there is one. We were told that on Windows the log files aren't produced consistently."

I look into it for 5 minutes. It turns out no one bothered to configure a log file in the INI file. So, no logs were produced.

I'm dumbstruck. It's the latest in a long string of stupendous tales the previous developers have told the business people and test team. Lots of mythology around why the system acts oddly ... memory leaks, bad casts and pointer references, 'Windows can't do the log files', 'Windows sorts differently', 'You need to enter the password in all caps... No, not with the shift key, you have to enter it with CAPS LOCK'

WTF?

To be fair... I am hearing all these anecdotes second-hand and filtered through the non-technical team. But, taken as a whole I can't decide whether it lessens my confidence in the BAs and dev management, in that they couldn't successfully call the engineers on their bullshit... or if it just confirms my opinion that the engineers were lazy and outright lied about how things worked because they didn't want to take the time to correct the problems.

triumph! ... oh, dammit

Friday was a bittersweet day.

On our horrible project-released-every-month, they are frequently late starting their regression test, and very often late with the release. In 2007, it was only released on-time twice.

As bad as that is, the good(?) thing is they don't release until their regression test says the only differences are the ones they expect. Unfortunately, that typically means a team of 12+ BA's, developers and testers work the weekend.

But not this month. We started the regression test when we were scheduled to on Monday. And, rather than posting the release on the drop-dead Monday date, we passed the release off to customer-facing site on Friday. This is the first time in years that that has happened.

The process-improvements Jeff and I have been insisting on deserve some of the credit.
Odd things. You know, completely out-of-left-field things like code-reviews and communicating. It's unclear how much of this month's success was the amount of work included in this release, and how much of it was our process changes.

Unfortunately, the day of triumph was made bittersweet by Jeff's resignation. Probably not accurate to call it a resignation, since he was a contractor and decided not to pursue extending his contract. Or, to be precise... not wait until the final day of his contract to find out if they were going to extend his contract.

I don't blame him for finding something else, and I may follow him soon enough. The monthly release meat-grinder can be made less painful... but it'll never be fun.

ready. set. go?

I'm coming to the realization that I was so focused on leaving the previous employer that I didn't think critically enough before accepting the offer at current employer. Beyond the many dead horses I've already beaten, there were plenty of hints to which I should have paid attention prior to accepting the offer.

More mixed feelings today after a meeting discussing our project's migration from usage under the current application framework to its replacement over the next 2-3 years. Felt good that our hard work to stabilize the crumbling infrastructure is recognized by the business people. Felt worse when I realized that 2+ years into a multi-million dollar project, they're finally discussing the actual mechanics and workflow of how both systems are going to be developed and maintained together. "Oh yeah... we want to release in October. We need to figure that out."

Nearly all the positives about the new job have been snuffed out. There is the potential for it to get better, but it's hard to hold on to the glimmer of hope. Other than feeling like I'm giving up, it's getting harder to find reasons to stay.

Friends at 4 different employers are looking for people... positions with varying levels of awesomeness. Or, I could strike out on my own and find something different.

But, what do I want? That's the million dollar question.

Someplace more engineer-y than my most recent work in content publishing or healthcare. Some of the work was great and challenging... other parts have been mind-numbing or downright eeeeeeeeviiiiiil. Not that the previous work in simulation was fluffy kittens.

Someplace that views R&D as a vital part of their business plan, rather than whining by engineers for 'fun' work. Maintenance can be fun -- debugging an issue, finding the cause of the crazy and esoteric problems is like unlocking a puzzle and can be very rewarding. But, it's not something that you look forward to doing as your sole activity for the next 3+ years.

Something more back-end rather than UI or web-applications. I'm pretty sure that new fangled interwebernet thing will never work. It's all TUBES! TUBES I TELLS YA!

It'd also be nice to land someplace where I could use Python for more than just throw-away utilities, and not be viewed as a rabble-rouser.

pink eye!

Liz's brother's family visited us for a couple days while they were in town for a funeral. Bart turned us on to one of our new favorite shows, Corner Gas.

Good silly fun. Needs more explosions.

waaaaaah?

I was feeling good this morning. Ran the regression suite overnight through Purify, and it had found some problems. Uninitialized memory references. Who would have thought that hundreds of 5-50 field structs in a 300 kloc code base with no standard initialization routines would have this problem. Bizarre.

So far I've resisted the urge to go fix all the potential instances of the problems, and only fixed the problems exposed by the regression suite. Maybe for next month's release.

Then I spent about 4 hours in conference calls. At about the third hour in I realize the crick in my neck that I'd blamed on sleeping oddly was more in fact from the previous day's conference calls. Jeff helpfully points out over IM, "Yes, this meeting is a pain in the neck."

Then I finally get a response from technical support on 2 of my tickets, after they'd spent ~3 weeks in a black hole.
"Due to ... blahblahlbha... we cannot install open source applications on any servers."

The offending applications? Zip. Unzip. GNU Make.

I can't decide to laugh or cry. The HP-UX server in question already has the GCC toolchain, GNU tar, ant, CVS, CruiseControl and the list goes on. Not to mention widespread use of Hibernate, Spring, ehcache, and tons of Apache and Jakarta projects throughout our Java and .Net products. WTF?

I've learned my lesson. Attempts at following procedure will only be made as a last resort. I need anti-action-item-Wonder-Woman-bracelets to deflect IT-related action items onto my coworkers.

Speaking of playing dress up...

I have to keep reminding myself I have better things to do than spend $250 on t-shirts.

further lessons in not believing anyone

More whining about work.

It's becoming increasingly apparent that the previous development staff of Project A were lazy. Definitely not stupid, only people confident in their brilliance could produce such a poorly documented and nightmarish code base.

Lazy in terms of, "Hey, that's acting weird... it seems hard to figure out too. I'll blame X and the business people will live with it."

The latest example is the supposedly 'inconsistent' regression test results. When Jeff and I joined the project, we were repeatedly warned in reverent tones of the odd non-deterministic regression test. The first time the 10k+ bills in the regression suite are run, some bills fail. If you run those bills through again, they work.

On the face of it, it seems very odd. The way it was presented to us it seemed that the failing bills were random, and on re-run the identical bill would produce different results. Various things were blamed: memory leaks, buffer overrun, bad casts.

As we dug into it, it became clear that wasn't the case:

• the bill processing engine wasn't re-started between the failure and success.
• for at least one large set of the failing bills, the same bills fail every time the regression test is run.
• The regression test's preparatory script actually modifies the bill in such a way that they become illegal bills
• the engine sees the illegal bill, and tweaks it such that works again
• but, many of the failing bills are only partially tweaked because they have manual override codes. The partial tweaking sets the bill up to fail the first time, but corrects things enough that it will work the second time through the system.

Definitely a bug in the engine. The data that's reset by the prep script shouldn't make it behave that badly.

python + elixir + pyyaml == yay!

And so... I'm playing with a little toy script to ease some pain at work. We've got a bunch of bills in a very large database, the bill data our application reads/modifies is split across a number of tables.

At the moment, the developers manually run SQL scripts to peek at various bits of data. Definitely a huge waste of time.

So, I'm playing with Python + Elixir + PyYAML to get a script that I can just pass in the bill ID and it'll query the 5-6 tables and serialize the bill to something more human readable. If I play my cards right, I'll never have to deal with Toad again.

Elixir works its magic and I can query my database. The autoload didn't work, and there are a couple tables with 50-100+ columns. Serializing it to YAML without repeating myself is now the trick.

I'm sure there's a better way to do this, but here's what I came up with... applied to the Elixir tutorial. Not the most exciting thing ever. But, it's the start of building a better testing framework. Doing the same for the real tables will make it much easier to compare a bill before and after running through our application.

#!/usr/bin/python

# -*- coding: latin-1 -*-



from elixir import *



from yaml import load, dump

try:

    from yaml import CLoader as Loader

    from yaml import CDumper as Dumper

except ImportError:

    from yaml import Loader, Dumper





def _toYamlRep(ent):

    """

    Given an elixir entity, query the entity's members via its __dict__ 

    and return a dict

    """

    ret = {}

    for (k,v) in ent.__dict__.items():

        if k.startswith('_') or k == 'row_type':

            # don't print out the 'hidden' keys

            continue

        if v:

            ret[k] = str(v)

    return ret



class YamlEntity(Entity):

    def toYamlRep(self):

        """

        Wrap the _toYamlRep() dict in another dict, use the class' name as the header.

        """

        return {self.__class__.__name__ : _toYamlRep(self) }



class Movie(YamlEntity):

    title = Field(String(30))

    year = Field(Integer())

    description = Field(Text())

    director = ManyToOne('Director')



    def __repr__(self):

        return '<Movie: "%s" (%d)>'%(self.title,self.year)





class Director(YamlEntity):

    name = Field(String(60))

    movies = OneToMany('Movie')



    def __repr__(self):

        return '<Director: "%s">'%(self.name)





def main():

    metadata.bind = "sqlite://"

    setup_all()

    create_all()



    rscott = Director(name="Ridley Scott")

    glucas = Director(name="George Lucas")

    alien = Movie(title="Alien", year=1979, director=rscott)

    swars = Movie(title="Star Wars", year=1977, director=glucas)

    brunner = Movie(title="Blade Runner", year=1982, director=rscott)

    

    session.flush()



    for m in Movie.query().all():

        print dump(m.toYamlRep(),Dumper=Dumper,default_flow_style=False)



    cleanup_all()



if __name__ == '__main__':

    main()

And, here's the output:

Movie:
  director: '<Director: "George Lucas">'
  director_id: '2'
  id: '3'
  title: Star Wars
  year: '1977'

Movie:
  director: '<Director: "Ridley Scott">'
  director_id: '1'
  id: '4'
  title: Alien
  year: '1979'

Movie:
  director: '<Director: "Ridley Scott">'
  director_id: '1'
  id: '5'
  title: Blade Runner
  year: '1982'

cruisecontrol == teh suck

Every time I try to dive into configuring CruiseControl, I hate it a little bit more.

can it be? finally done? ... WTF?

And now, the servers have been installed (all except for the HP-UX I may give up on).

after the following loop through the tech support desk:

1. go to system A
2. go to system B
3. go to system C
4. go to system D
5. go to system F
6. no, go to system C. enter text 'XYZ A'
7. FAIL
8. no, go to system C. enter text 'XYZ B'
9. SUCCESS

The admin rights have been granted.

It seems obvious now, but if you're not given a definitive answer when you ask "Doesn't Umbrella Corp already have a pool of licenses we can pull from?", keep asking.

Turns out, we had the licenses all along. SWEET ZOMBIE JESUS, that was good times.

progress?

When last we saw "Steve's lame-assed adventures in IT", I was relating my struggles with our IT department. This morning's update:

• I reply, "I don't know what group name you're asking for? How do I find that information?"
• Tech-support person #6 replies, "Global group used by your team to access servers."
• I reply, "I have a 'global group to access servers'? I log in using my XYZ domain account. I don't know what group you're asking for. Is the global group one of the access groups listed in service request system F?"
• Tech-support person #6 replies, "Yes, global group is a access group."

I don't know if this is progress or not.

Further complicating matters... the process improvements Jeff and I have suggested appear to have helped us meet this month's release. The group's communication is improving, the code reviews caught some subtle problems, and it seems like meeting the deadline may not only be because of the handful of items they dropped off the release plan. And, Jeff and I are spitballing some ideas to for a unit testing framework so the developers can test their modifications without manually running SQL statements to verify the result of their changes.

It seems like we could be successful. If only we're not ground up by the monthly release chaos.

But, is it worth it? I'd hate to run away after only 2 months, but it gets very discouraging. There are at least two friends who have jobs to fill, one unknown but potentially awesome and another known and good-to-awesome.

I don't feel like I'm growing technically. But, I'm definitely growing in terms of dealing with projects, customers, and other developers onshore-and-offshore. Maybe the pain is worth it. On the plus side, Jeff and I have the complete support of the business-side to make the changes we're planning. They're suprisingly enthusiastic.

are you there Mordac? it's me steve

Because the purpose of my life is to serve as a warning for others, please note the following:

1. Don't spend the first 3 weeks after your initial "I need software X" request, lackadaisically monitoring the request's progress every 2-3 days. Expect to spend 1-3 hours per day following up on e-mails and on the phone.
2. Don't bother trying to navigate the 'helpful' self-service website, or the dozen+ service request web apps. Go directly to the Help Line. While one-on-one interaction with actual people is scary, at least there will be someone to hear your plaintive cries.
3. If tech-support person #1 helpfully forwards your e-mail to person #2 for clarification, don't assume that person #1 would take note of person #2's out-of-office reply that says they'll be out for the rest of the month.
4. Don't assume #3 wouldn't happen twice. The same day.
   
5. Assume every person 'helping' you is actually actively preventing you from reaching your
   goal through a clever misinformation campaign meant to drive you slowly insane.

As the owner of the action item, it does make me feel slightly better to be an obstruction to the people waiting on me to get this done. Their pitiful cries bring delight to my cruel, cruel heart.

Last week's status meeting:

Person Z asks, "Steve, any progress on ?"

I reply, "I've got it installed on the two wintel servers I had admin rights to. I can't find anyone to give me a straight answer on who owns the other two wintel servers, or the 'right' process for requesting admin access. I've entered a Unix service request on the fifth server, I assume someone may see it eventually."

The assorted people in the room nod sympathetically, apparently my struggles are par for the course.

Project Manager F asks, "Is there anything we can do to help?"

"Pray."


Mordac's latest trick, masquerading as other IT service members:

• As persona #1, point me to intranet URL #1 telling me to use service request system A to apply for admin rights.
• I submit request, push the approval through my management chain.
  
• As persona #2, reject request. "System A is only to request admin access to your desktops. Not servers. You need to follow the set of instructions at this URL."
• URL #2 describes in the vaguest way possible how to gain access to various intranet web applications through service request system B
  
• I reply, "WAH? Person #1 told me this, and its clearly documented at URL #1. If that's wrong, it needs to be updated. I follow your instructions, but I don't see which access group I need to belong to gain access rights, can you clarify?"
• Persona #2 forwards it along to persona #3.
  
• Persona #3 says "You need to follow the instructions at URL #3, and use service request system C."
• System C looks like its asking for the right information. I submit the request.
  
• The request is rejected by Persona #4, "You can't do that for your specific user id. You have to enter your team's group name."
• This is the first I've heard that my team has a group name.
  
• No one on my team is aware we have a group name, or what it may be. Not even those who already have admin on those servers.
  
• No reply from Persona #4 yet.
  

project A makes baby jesus cry

And so... for some reason I'd gotten it into my head to volunteer for Project A at work. Project A is a rules engine for processing ... things... Myself and another fellow newbie on the project (Hi Jeff!) are slowly coming up to speed on the crazy.

How crazy? Let me count the ways...

• Release every month!
• Without a project manager, development manager, or release manager. Who needs 'em? Crybabies.
  
• We can't control the # or scope of change requests coming in each month. State regulations drive all the changes to the system. Some nebulous decision process allows us to occasionally drop some changes from the queue... but we don't know which until the deadline has been blown.
  
• Crumbling 12+ year old code base. Not given love or documentation over the years. Occasionally tossed a bucket of fish heads. You can tell which dark corners survived from the halcyon days -- they use the hacked-in exception handling in what appears to be the correct way. While I appreciate the cleverness of adding exception handling to C (preprocessing macros around some setjump/longjump magic), I'd appreciate it more if anyone had bothered to write a brief document describing said 'right' way. An example in the .h file? Pshaw! That's for suckers! In the 3 weeks I've spent diving through the code to correct memory leaks, there's at least 4-5 different exception handling idioms. Many possibly broken sections of code, swallowing exceptions with no comment to explain whether the author did accidentally or on purpose. If there aren't comments, it's usually right... for certain values of right. If there are comments, the author clearly thinks exceptions either work like Java's or has no clue.
• Functions are named as ambiguously as possible with regard to whether it returns a reference to a list that shouldn't be modified, or a copy of the list that's safe to modify and needs to be cleaned up by the caller.
  
• It doesn't matter that developers create the builds pushed to customers, right?
  
• Oh, and developers have been doing the source control labeling too.
• Oh, and they're doing both of those tasks half-assed
  
• The developers have been too lazy or too scared of the HP-UX makefile to allow it to work without manually copying all source files from their CVS checkout directory to the application directory.
  
• You know what'd be a great idea? Basing the fancy new .Net-based Product B's rules engine on Project A. Wait... let's add a Java JNI wrapper around its re-packaged Project A. Awww, yeah... now that's good and f*^@#$ed up.
  
• Cherry on top: some genius decides to branch to support Project B. "Branches are neat! Wait... branches are hard... oh well, we'll just branch this one directory that has the DAO stuff, that code definitely has to be different between Project A and B. That's what branching is for, right?" The branched directory also contains nearly identical files that will be slowly, and not-so-slowly , diverging to meet each project's mostly identical monthly release requirements. What? Labels on the branch/trunk to indicate merged code? Nah, that'd be too helpful. I should consider myself lucky that the branch has only existed for a year.
• Oh yeah, we're releasing Project B mid-Summer. Sweet!

Somehow, I'm the calming influence on Jeff. Probably up to the point where he reads this rant. C'mon, we're in it together! You know, like Musketeers! But less flouncy.

I'm pretty sure I'm living in a sitcom written by The Daily WTF. The alternative is unthinkable.

This is Mark's cue to waltz through with a comment where he doesn't say a thing. Which I appreciate.

more ponytails than should be allowed by law

Decided to go to the April UJUG meeting a couple nights ago. The presenters varied a little in quality, but were average to great. The topic was interesting, I would have enjoyed more "What went horribly wrong" war stories.

I thought it was telling that even though Maven was held up as a savior for many of the projects, everyone who spoke up mentioned their love/hate relationship with it. It sounded like the LDS church's team had embraced it the most, and a big part of their success with it appears to be because they've dedicated 2-3 engineers to supporting it full time within their organization.

Turnout was huge, 100+. I think I prefer the smaller, and less formal, UPyUG meetings. And it's not just because I think software developers with long hair look silly. So many ponytails at the UJUG meeting. And at least one beret.

Spring, best thing since sliced bread?

I've been reading a lot about the Spring Framework lately. It's been aggravating me... realizing how much easier it could have made the last 2 years of my life, if I'd dug into it before starting on my last big project.

I'm enjoying Spring in Action. Only a few chapters into it. So far a good introductory book. I like the light tone of the examples, but the jokes are becoming grating.

I also picked up Expert One-on-One J2EE Development without EJB. I'm pretty sure it wins for the creepiest cover on a technical book ever. Kids, if he pulls up to your playground in a ice cream truck, RUN AWAY!

what? just because we don't have a customer we have to stop working?

The job switch has been... odd. Spent the first week and a half scrambling, reading non-stop to catch up with the rest of the team on the Java frameworks we'll be using.

Spent the second week and a half wondering what I'll be working on. The original project was put 'on hold' due to lack of business funding. We'll be shuffled off onto different projects for the time being, likely never to return to the original project.

It's good times.