Today we got a lot of painting done. We are almost done with the ceilings. I got stung by a scorpion and a big glob of paint in the eye, so it was lots of fun. There are a bunch of new pictures up on the gallery. I’ll have to elaborate more later.
Today I didn’t have much time to spend on the condo. It was my mom’s birthday, so we got together for dinner. I stopped by home depot after the festivities and got a 5 gallon bucket of white ceiling paint, and 3 sample quarts of various colors. I also got some painting supplies, and checked out the bathroom vanity tops. I need a 71 inch one in the master bath with two sinks, which seems to be a custom order item everywhere. The best price so far seems to be ~$700 for a granite one at Lowes. It’s not a bad price for granite, but I don’t think I want to spend that much.
After picking up the paint, we picked up some poster board at Fry’s to paint samples on so we can move them around. We arrived at the condo at around 11 and my sister Lucy painted the posterboard. I think the main color is too light, and the darker brown is definitely better, but I have to wait to see what they look like in the sunlight. We hung around until about 12:45 and did some paint prep, masking some of the trim and removing outlet covers. Mike, Paul and Jac also removed some more linoleum and trim from the kitchen. Tomorrow morning we should start painting ceilings, and hopefully we’ll be able to start on walls tomorrow as well.
I am also trying to come to a decision about whether or not to redo cabinets. I was looking through an Ikea catalog last night to see if they had any good paint schemes, and noticed their kitchen cabinets at least look pretty nice. I looked at them a bit online and downloaded their kitchen planner program. It looks like it would be about $3000 to replace cabinets and counters with Ikea gear, but I’m a little worried about quality. I’ll have to go to the store and take a look. My uncle has Ikea cabinets I think, and he seems to be pretty picky about quality, so maybe they are good.
I have no pictures tonight because I forgot my camera, but I will take some in the morning to show the color samples and further progress.
So, as you may have heard, I recently purchased a condo. It came with a bunch of money for redecorating expenses, so I was planning on doing some work to make it nice. It turns out the people trashed it, and it needed to be pretty much gutted. I took pictures of the place for record and they are here if you want to see the extent of the nasty.
I, along with a bunch of helpful family members have been spending the past week or so cleaning things and ripping out flooring, etc. It is already looking much better. Tomorrow I hope to start painting. I am going to paint the ceilings “ceiling white” and the rest of the tile/paint selection can be seen here:
The top two colors will be the paint colors. The right side will be the main color, with the darker color being an accent color on various walls. I’m not totally decided on any of this, but those are the choices for now.
I’m going to try and post daily or whatever and update on the progress. You can see the full gallery of photos here.
So, for today, Mike and I started working early and started with the bathroom. We installed some new faucets in the master bathroom earlier, but finished hooking up the drain levers today, so they are fully operational. I also started dismantling the toilet in the master bath, which will be replaced after the tile goes in. Then, I started washing all the walls while Mike worked on removing moldings where tile is going in. We will paint and lay the tile with them off, then clean them up and put them back on. He also pulled out some remaining tack strips where carpet is being replaced with other flooring, as well as some tile in the living room which will be replaced with the new tile. I finished washing almost all of the walls, so I’m pretty happy about that. Here’s a few action shots:
So I’m switching a bunch of custom written DAO’s for SQL server to NHibernate. NHibernate seems almost as good as the regular Java hibernate, so it’s pretty nice. The custom DAO’s were a big pain and this is much nicer and less bug-prone. I wish we would have written unit tests for the old objects, but it was never done. For the NHibernate transition, I decided to implement them. I have always wondered what the best approach was for testing DAO’s, since they affect the persistent data storage, and it’s hard to control the contents of your database. After reading a few articles, I decided the best approach was to have a special database just for testing. The tests tear down and rebuild the database before they run. This can be sort of slow, but it doesn’t seem too bad in our case. So, we end up having the following databases:
That looks like a lot of databases. I wrote a simple program using the SQLDMO COM object to dump the database schema (from the CI dev copy, making it a canonical source of the schema) every night and commit it to CVS if there are any changes. That was fairly simple to set up and provides you with a schema to build a blank db at any time, which completely automates maintenance of the testing datbases, so we are down to 3 we have to maintain (semi-)manually.
Now, the unit tests can assume the database is empty and create objects in it at will. So far, so good. My initial approach involves one NUnit test object per NHibernate object. I started with one method called NewObjectTest in each test class, where Object is the name of the object. This has multiple Assert statements to check that each property is being persisted, which is considered a bad practice. The alternative seems very tedious, so this trades quicker implementation with less precise test failure reporting.
Everything was going well until I hit the first foreign key constraint. I realized that many of the database objects are heavily dependent on other ones, so that complicates the tests. If Object A is dependent on Object B, then Object A’s test must create an Object B for the FK, which breaks the independence of the tests. It seems like the best way to solve this would be to make the tests run in order and pass objects to each other, but there doesn’t seem to be any facility to do that in Nunit, so I’m still trying to decide what to do.
I spent the entire day today trying to fix a bug with a certain Sanyo phone. This is a java phone that seems to have a broken garbage collector. When doing heavy Image operations, it piles up the uncompressed versions of the images in memory and then eventually crashes. If you call System.gc() it cleans up, so that is the workaround, but you have to know where the pile-up is happening. Sanyo’s phones are all really ugly too. You should never buy one. I think Samsung is the best CDMA phone vendor.
Anyway, what a depressing day of work. Now I’m just wasting time until I can go home, cause I’m sick of working on it.
So, I said I would say more about BREW and gcc. I have a Makefile that works well with gcc/gnu make to generate Win32 executable DLLs for the simulator. I also got ARM stuff to build with almost full C++ support, but I haven’t tested it on a device yet so I’ll hold off on posting that. As soon as the devices get back from Qualcomm for test enabling, I will test.
Anyway, here we are:
CPPFLAGS=-g -I “C:\program files\BREW 3.1.4\sdk\inc” -I . -D AEE_SIMULATOR
CC=g++
genesis: genesis.o AEEModGen.o AEEAppGen.o
g++ -g -shared -mno-cygwin -o genesis.dll genesis.o AEEModGen.o AEEAppGen.o
clean:
rm -rf *.o *.dll
all: genesis
I got gcc working to compile BREW apps for Win32 in the simulator. The key is the -mno-cygwin option to gcc. I will elaborate soon on the full rundown. I still don’t have the debugger quite working. It seems to be able to load in the symbols from the DLL, but it doesn’t hit the breakpoints properly. I think the situation is tricky because we are debugging an EXE that has no symbols that dynamically loads a DLL with symbols via Eclipse/GDB, which is a pretty exotic setup.
I can also say that the Microsoft debugger I mentioned previously is pretty user unfriendly. It’s kind of like command line gdb, except more clunky, from what I could tell.
So, I think up until a little after I graduated from college, I was a pretty closed minded person in terms of software development. I felt that my education was a waste of time and I knew all there was to know. Some of this was due to personal arrogance, and some of it was due to the lack of an environment which drove me to do better. I think one of the turning points for me was my first JA-SIG conference. JA-SIG is an organization of University IT staff who get together and talk about Java in their organization. I went in thinking I knew quite a bit about Java, but left realizing there was a lot of cool stuff I’d never done before. It was the first time I saw the Eclipse IDE, which converted me to a die-hard vi/command line person to an IDE user. Things like continuous integration, unit testing, web services, etc. were new things I hadn’t tried and didn’t really think I needed to know anything about.
Anyway, the whole realization I had starting with that conference was that you need to keep an open mind and try new things with respect to technology. You should also seek out the experts in your domain and follow their examples. In terms of their conventions and styles, you may think you can come up with the best solution yourself, but experience of others cannot be written off as useless. Follow their example, and if it doesn’t work, revise it. And constantly search for ways to do things that other people have come up with and you haven’t seen yet.
Once you start following these philosophies, you will find that you are discovering all sorts of new and exciting ways to improve your productivity instead of following the same boring old routine.
Basic intro: BREW is a C API for programming cell phones. It is mainly for CDMA devices using Qualcomm chips. Basically, in the US it is used to program Verizon phones. All of the other (major) carriers use Java and J2ME.
Getting started with the BREW dev tools, the environment seemed really nasty to me, so I was going to try to swing something cleaner. They tell you to use Visual Studio, but all of their samples reference VS 6.0 although they have a tool set and one document for VS.NET 2003. Even that version, however, is outdate since VS 2005 is out. On top of that, VS is getting notoriously expensive (up to $10k/year per developer for some MSDN plans). So, in order to avoid this hell of versions and paying lots of money to MS, I ventured to get BREW stuff to compile under Eclipse using CDT.
CDT is a little out of place on Windows, you have to install Cygwin to get it working right. You should install Cygwin BEFORE CDT, otherwise bad things happen. The default “managed make” setup didn’t work for me, so I started writing makefiles like a normal person. I managed to get a build of the BREW app with GCC, but it would hang when I tried to run it in the BREW simulator. So, I switched to Microsoft’s compilers to see if it would work. After a bit of farkling, I was able to build the app with cl.exe and link.exe and run it in the emulator. For anyone that wants to avoid Visual Studio, you can now download the compilers for free (minus the IDE) from here:
http://msdn.microsoft.com/visualc/vctoolkit2003/
I believe those would be the VS.NET 2003 equivalents, so maybe they are a bit out of date, but they work fine. You may also need the platform SDK to get windows.h etc.
Now, I had a build that worked.
The next step was to actually do something. I’m a little rusty on my C and BREW uses some particularly nasty constructs, so I ran into a lot of segfaulting in my first run. Up until recently, I wasn’t much of a debugger person, but now I felt that I would need the debugger to get this BREW crap working in a timely manner.
CDT only supports GDB for debugging at this point. I was able to attach GDB to the brew simulator, but I could not seem to get debugging symbols loaded into GDB for my app’s DLL. Microsoft’s C compiler creates .PDB files which contain debugging information, which I don’t think GDB can understand. So, that was a no go. My next step is to try these tools to see if they
are usable without Visual Studio:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
We shall see…
There are pictures from our Havasu trip here:
http://chaos.wold.org/gallery/view_album.php?set_albumName=havasu
Al's Blog 