31/10 earning a degree in socketry

Most of my work daily is dealing with sockets in C#, but for reasons I won't expose at the moment (*cough* *cough* *cough*) I really need to brush up on my lower-level networking skills, specifically BSD sockets by...around mid-november.

In addition to a C#-related book, I purchased the following books to essentially relearn what I've been doing for the past 3 months at a much lower level.

"UNIX Network Programming, Vol. 2: Interprocess Communications (2nd Edition)"
W. Richard Stevens; Hardcover

"Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition"
W. Richard Stevens; Hardcover

"The Protocols (TCP/IP Illustrated, Volume 1)"
W. Richard Stevens; Hardcover

"The Implementation (TCP/IP Illustrated, Volume 2)"
Gary R. Wright; Hardcover

Regardless, good reading material, and pretty decent coffee table literature in any developer''s household.

[tags: sockets, network, programming, tcp, ip, bonjour]

31/10 plastiq

Wells Fargo (my bank of choice) sent me another card today, and I now have every style card they offer.

"Business Deposit Card" "ATM Card" "Gold Check Card" "Business Platinum Check Card"

The best part of course is that, I've switched to using mostly cash to prevent our over-zealous government from tracking my purchases. The "Business Platinum Check Card" will come in handy when it comes time to purchase new hardware though.

[tags: wellsfargo, bleep, nsa]

29/10 BuildFactory 1.0.10, Codename: Starbucks

Had it not have been for a 6:30 am big ole' cup of Mocha from Starbucks this morning, I probably wouldn't have been buzzing enough off caffeine to hunker down and release BuildFactory v(1.0.10)

I'm still struggling with a more fine-grained level of Subversion integration, which is my major change that will cause me to bump the version to 1.1; so there might be a BuildFactory 1.0.11 before Subversion integration "stops sucking." For now, I'm probably shooting myself in the foot in terms of marketing, but I recommend using your pre-build scripts to do any subversion/perforce/cvs integration instead of the built in facilities, because they (admittedly) suck.

Anyways, here's a direct download link, and a link to the changelog.

[tags: buildfactory, bleep, cocoa, continuous, integration]

28/10 it's been fun

Warning. This is a rant.

No, really guys, its been a blast. The recent events regarding this farsical "war on terror" (like Christopher Soghoain's case, erosion of due process, and the systematic attacks on checks and balances) are really starting to wear on me. I figured I'd make it clear that unless convinced otherwise every single incumbent politician on my ballot, I will vote against. I want the America that I was forced to pledge allegiance to in grade school, we have politicians shouting freedom while actively working against it every single day in office.

When I hear another “talking head” on television while standing in line at the bank, coffee shop, etc, talk about “America”, or “freedom,” I cannot begin to fathom the irony in their statements, regardless of what cable news network they are on, it is quite obvious that they know not the meanings of the words they so often misuse.

I am of a younger generation, those born towards the latter end of the cold war, those born in the Reagan Era (or the tail-end of that guy who grew peanuts’ era). As a young twenty-something male, I have never been inspired, I have never known leadership, I have never felt connected to any sort of democratic ideal, and frankly, I have never truly lived in “America.”

Read the full entry »

27/10 Code Marshalling in Mono, Part 1/5

introduction

I've been talking a lot lately about using C# (via Mono), mostly because I've been working a lot lately with C#, instead of my Cocoa projects. I'm not exactly certain of the "audience" that bothers to read my inane bloggings, but I figure its fitting that in part one of this five part series I explain first, what Mono is, and secondly, what is "code marsalling" and why it's necessary

For starters, Mono is an open source project sponsored by Novell to provide an open source .NET framework (i.e. compatible) to allow developers to develop and deploy applications that are cross-platform across Mono-supported platforms as well as Windows. Unlike certain aspects of the .NET "initiative" put forth by Microsoft, such as Visual Basic .NET, Visual C++ .NET, Visual Fortran .NET, Visual ALGO .NET, ad infinium, Mono is primarily based on C#. There has been work recently in support Visual Basic.NET under the Mono framework, but I get severe nausea every time I think of Visual Basic, so we'll skip that topic for now. I am not however trying to explain what Mono is, they have a FAQ just for that, I want to explain what "code marshalling" is, why it is important, and of course, how it will make you rich beyond your wildest dreams.

Read the full entry »

20/10 dear america

just a quick note.

if you're going to drive like a wreckless assclown, at least have the common sense to take the magnetic "MyCompanyName" sign off the side of your car.

wouldn't want you to lose any aluminum siding business or anything...

[tags: assclown]

20/10 In search of a synergy-enabled enterprise workstation

Over the past couple days, I've been evaluating parallels, and I've tried to like it, really I have. There's only one, no two, major flaws with Parallels, first being its abhorrent stability, secondly its about as robust as a pineapple (pineapple's are notably not robust in the fruit world, just ask your grocer). While I was doing some reasonably heavy I/O tasks in a virtualized FreeBSD machine (eggplant.local) I started up my SuSE Enterprise 10 virtual machine (tomato.local) and my entire iMac came grinding to a halt, causing me to lose all my unsaved work, etc. My intel iMac is not short on the performance stick either, 2Ghz intel Core Duo and packed with 2GB of RAM, its a powerful machine, and watching it lock up completely is nothing short of absolutely infuriating. In the realm of robust-osity, Parallels flunks the test as well, to back up (or clone) a virtual machine's disk image, you must completely halt the virtual machine, say a prayer, tap your red slippers together three times and hope it works. The "Clone VM Disk" option is about all Parallels has in terms of virtual machine management which, after usng VMWare extensively on another project, is quite disappointing.

where's the synergy?

This leaves me at a cross-roads, its becoming increasingly ineffecient to keep numerous x86 machines lying around for testing various iterations of Linux, Windows, and other operating systems (FreeBSD/OpenBSD/Solaris), so the best option available is to virtualize. As Parallels is a decent one-VM solution for Mac OS X, and VMWare doesn't exist on the Mac platform yet, the best option is to have the company purchase a new Linux-based workstation that will handle various virtual machines. The machine should be a new machine, capable of running no less than 4 virtual machines in VMWare with ease, and should jive with Novell's SuSE Enterprise Linux 10 (which I might say, is the most impressive distribution I've seen to date).

Slight problem, I've never actually purchased a new PC, whoops. I've bought two new Apple computers, but all my PCs are second-hand in some form or another. I refuse to purchase from Dell, so that leaves me with IBM, HP and Sun to choose from (any good vendors I missed?). I've been most impressed with IBM's IntelliStation Workstation line thus far, the IntelliStation M Pro Express Model is definitely looking like a viable choice. Sun isn't lagging too far behind in the pursuit of a good Linux workstation/vmware server with their Ultra 20 M2, it is however a bit more expensive point for point than IBM, but Sun's machine is utilizing an AMD Opteron (dual core) processor, versus IBM's M Pro Express which is built with an Intel Pentium 4 (3.4Ghz EM64T). The machine needs to be solid, and well supported too (a good warranty is a must of course) but there's no restriction on Intel/AMD, so long as it runs SuSE, and VMWare.

The options are numerous to say the least, but the right choice needs to be made, as virtualizing as many servers as possible will not only increase my ability to test, deploy, and deliver on those respective platforms, but will help grow the business as well ("We want this to work on Solaris 10, can you do that?" 'Sure').

Opinions? Ideas? Suggestions? More Cowbell?

[tags: ibm, sun, suse, vmware, virtualization]

19/10 Backing up Perforce

I spoke with Dave (of geekisp fame) earlier this evening about a decent strategy for backing up my Perforce repository from my FreeBSD machine (FreeBSD orange.local 6.1-RELEASE) onto a local machine (i.e. another machine on the LAN) as well as a remote machine (such as a share on strongspace).

My "plan" for creating viable, and constant backups of my Perforce repository is as follows. Every morning at 4:25a.m. a perforce checkpoint is generated as well as gzipped tarballs of every depot in the repository (//depot/... //user/... //client/... //contrib/...). The checkpoint files, as well as the depot tarballs are copied into a new directory with the date (ex. 2006-10-19) and then placed in a centralized backup directory (/usr/backups/perforce). This entire directory is rsync'd over to my intel iMac following each successful backup. In the future, I intend on setting up a weekly rsync to a remote site. The rotating of the logs will also become a weekly thing as well, in effect, a backup will be made every monday, tuesday, etc, and locally backups will be kept resident for only the week, remote backups should be kept resident for only two weeks. I've not yet selected a good remote host for these purposes, as a typical backup of my entire source tree is around 115MB.

My main backup script is as follows (note: this script is intended to be run with the zsh):

This script is quite rudimentary I think, and there's much room for improvement. I still need to find a good way of verifying valid backups from these tarballs, but for now, this should suffice. I would love any tips, or suggestions.

[tags: perforce, zsh, backup, sysadmin]

18/10 yuppie punk.

As I pulled into the Starbucks parking lot in my shiny blue Volkswagen after speeding back from my morning classes, I quickly turned down the Pennywise that was blaring from my stereos, and walked inside.

Catching a glimpse of my reflection in the glass door on my way out with a grande mocha, seeing the reflected image of some guy wearing a brown corduroy sport jacket, blue jeans and Birkenstocks, I had an epiphany of sorts.

I am such a stereotype. Mac user, Volkswagen, Birkenstocks, punk rock, need I go on?

Damnit.

[tags: mac, volkswagen, birkenstocks, lame]

18/10 Monkeying around with Xcode and Mono.

I'm doing a good deal of work now a days with C# (utilizing the Mono runtime) in the world of cross-platform enterprise development. Unlike most people doing .NET development, let alone Mono development, I'm using my Mac for the core of my C# development. Unfortunately (somewhat) projects like MonoDevelop (based on #develop) refuse to cooperate with my intel-based Mac OS X development environment, this is due to GTK# being about as Mac-friendly as well...GTK+ (personally I'm waiting for Qt# to become viable).

What is a Mac developer to do? Use Xcode of course! This presents a few problems, besides the sinking feeling you get after writing anything other than Cocoa in Xcode, namely, auto-complete. The .NET API is enormous, along the lines of the Java class library in terms of the sheer multitude of classes available, this makes a decent editor a necessity, and to take that a step further, having an editor that has integrated auto-complete a worthy companion. Xcode's "Code Sense" (similar to Visual Studio .NET's intellisense, just with a cooler name) ties into an index for all the Mac APIs available (Carbon, Cocoa, CoreGraphics, etc); Code Sense however does not lend itself to be interoperable with "foreign" languages (such as C#, and Portuguese). It's feasible to elaborate further on the subject, but it sucks. I've resulted to keeping a few Safari tabs open with the Mono Documentation open within it (since Monodoc is based on GTK#, it won't work either).

The other major issue that makes development much more comfortable is simple syntax coloring, which Dru of Druware has solved with the following Xcode language specifications, which you can install on your system, restart Xcode, and viola Xcode now will color C# files properly.

There are other obstacles of course to developing C# code on your Mac, such as choosing a proper build system; since Xcode supports external targets, it's quite easy to interface your Xcode C# project with NAnt. Debugging with Xcode and Mono is still a bit of a gray-area that I'd like to avoid, as I heard from this guy from my friend's brother's cousin that if you try to debug a Mono executable your "manhood" will fall off and run away and join a cult. It's true, honest.

My next C#/Mono related post will most likely relate to the native-to-managed interoperability, as C# requires some magic in order to call out to a native library, such as a custom package library, or just about anything else that may be platform-dependent that you wish to interface with in a C# executable. I figure I'll write about it as soon as I fix my own code, which I broke with a vengeance today resulting in a bone-crushing reproducible crash, oops.

[tags: mono, csharp, xcode, mac, gtk#, qt#]

16/10 i have all the answers.

I think I've finally figured out what I love so much about consulting, and in turn, working from home.

Immediately following conference calls, I can sit at my desk imitating some of the people I work with in goofy voices which leads to a good round of giggling like a petty school girl.


Reciting "will it be deployable on AIX?" in a Yoda-esque voice is a guaranteed barrel of chuckles no matter what time of day it is.

[tags: aix, consulting, yoda]

16/10 Running NAnt on Mac OS X

For longer than bleep. has been an actual company, I've been masquerading as a Mac developer, while in reality, C# has been paying most of my bills for the better part of a year. I currently develop C# on Mac OS X, and Red Hat Enterprise Linux, so I am somewhat atypical in the realm of C# (primarily .NET) developers.

Currently in my main C# project (some client work), I'm using Xcode integrated with a system of GNU/Make Makefiles, while not the most portable solution, it fit the bill when I originally started writing code (this project has been started from scratch). It is counter-intuitive however to have a build system in place that is not portable, with code that is. I became more convinced of this after attending Leo Simons' session at ApacheCon this past friday entitled "Really Big Builds." The Apache Software Foundation probably has one of the largest code bases in the open source world, most of it Java, but they still use a wide variety of build tools. The tools employed for building projects ranging from Cocoon to Tomcat are equally as varied, tools such as Ant, Maven and of course, good old shell scripts. How is this relevant to me? Portability of course, it is quite obvious that these guys have a good bit of experience in supporting numerous platforms, to where I can metaphorically stand on the shoulders of giants, and gain from their experience.

This brings me of course to NAnt. NAnt is in practice, and design, equitable to Ant, except built in C#, and targetted more at .NET/Mono projects. After a bit of research this past saturday, I discovered two things, NAnt is distributed in the Mono.framework distributed by the Mono Project, the second thing was that...NAnt has been dysfunctional at best in the Mac OS X release of Mono. I'll spare you the trivial details as to why it wasn't working (pkg-config nonsense), but instead link you to the appropriate bug report (#79671) in Mono's bugzilla, and display the fix for the error.

NAnt is run by a small shell script distributed by the Mono Project, this tiny shell script just needs to be modified to ensure that invocations of "nant" execute appropriately:



[tags: nant, csharp, mono, macosx, apachecon]

15/10 memory hog

I've had my 12" PowerBook (1.33Ghz G4) for over a year and a half now, and I finally ordered more memory for it. Mobile development has just gotten far too painful. BuildFactory, BugTrap, and Browsejour all aren't big projects, but when running numerous applications, while tackling thousands upon thousands of lines of portable-C#, I tend to notice that processes start to swap out.

By wednesday of this week, the memory will jump from 512MB, to 1.25GB.

About time.

[tags: apple, powerbook, crucial, memory]

14/10 Pre-/Post-Build Scripting in BuildFactory 1.1

In addition to staring out the window wondering if the skies could acheive a more depressing grey color on this fine October saturday, I've been working on BuildFactory again. I spend most of the week working on other people's broken software, the weekend is my time, for my broken software :).

One of the most requested features (where requests > 1) for BuildFactory is the ability to add pre-/post-build scripting, which i've pointed to before as one of the features soon to come. Unfortunately, I've hit a writer's block of sorts, I can't exactly figure out how I want to do the pre-/post-build scripting.

Pre-build Scripting

The current schema for how pre-build scripts would be called is as follows:


Where the ${PROJECTDIR} and ${PROJECTNAME} variables are filled in on a per-project basis at runtime. The pre-build scripting is a bit easier in terms of implementation as there aren't a lot of expectations of a pre-build script, logically, because nothing has been built as of yet, so anything that needs to be done most likely will need nothing more than the directory of the project, and possibly the project name. An invocation of a pre-build script for Adium that resides on my desktop would be called as follows:


Seems simple enough, no? The invocation of this script can be called linearly before the actual building of the Adium project begins, so the implementation overhead to a pre-build script is quite low. The only question right now of course, is this enough for a pre-build script?

Post-build Scripting

Post-build scripts are a good deal more complex in how they might operate in comparision to the pre-build scripts developers might have. I'll be the first to admit that the disk image generation in BuildFactory is piss-poor, and makes far too many assumptions (its issue #211 actually "DMG Generation is too fragile"). The better bet for a developer, to generate nightlies for example, is to add disk image generation into a post-build script and handle everything there, after certain other actions have been performed. In this scenario, a post-build script should only need to know where the built products are right? Yes and no, what if the post-build script then needs to rsync the nightly to a server for mass consumption? What if it needs to copy the results to an internal file server? What if, what if, what if, what if. There's so many things that could be done, unfortunately, there's only so much information "I" can offer the post-build script, so here's the tentative schema for post-build scripting:


DSTROOT, is the built products directory (build/Debug, for example), SYMROOT is the build directory, and OBJROOT would be the intermediate files directory. The latter two are most likely over-kill and thus not needed for most post-build scripts. The unfortunate part, is that I cannot really gauge if passing the build configuration (Debug/Release), or the build target is completely necessary, so this is something I would love feedback on.

For most projects, the Products, Intermediate, and Build directory options (now under "Advanced Options") won't be used, so the "best guess" string would be inserted. For a project like Bonsoir, a typical post-build invocation might look like this:


The latter two options would be left off, I don't really think they are necessary to include unless you implicitly set them. The post-build script is also more complicated in how it should be executed. Should the script be executed in a linear progression? In effect, pre-build, build, post-build and then proceed to the next build, or should the post-build script be spawned in a separate thread, in order to save time (time wasted on rsyncing files, or any other post-build processing that may be necessary). Since the post-build script would logically not be tied to any running build by the time it's invoked, it is logical to throw it into an extra thread, but would the extra complexity of the application be worth the hypothetical speed boost?

I've mentioned this to a few people before, but my uses of BuildFactory are actually quite lame in comparision to the actual capabilities of the application, I really just use it to build all my projects, nothing fancy, just build en masse. I am however, aiming to build it into a complete Xcode-based Cruise Control competitor, so the more feedback on how to build it into a more effective continuous integration tool, the better.

[tags: bleep, buildfactory, cocoa, continuous, integration]

11/10 dear starbucks girl

thanks for empathizing with me about my shitty day.

i agree that starbucks is surely a pretty chill place to work however, i'm trying to avoid wearing a work uniform, so software development it is.


[tags: starbucks, development, caseofthemondays]

09/10 buckle up.

I found out yesterday (or the day before, its all kind of hazy) that a developer who I hold in high esteem doesn't use a version control system. The developer shall remain completely anonymous, but news of this was somewhat depressing. I have sought refuge in the following analogy about version control systems, which I've written about before.

version control is like a seatbelt

I am still not too young to remember when there weren't such things as "seatbelt laws" in most states, most people approached the problem from a slightly darwinian perspective; those with enough sense will buckle up, as it is in their best interest. The same applies to version control systems, it is in the individual's best interest to use the "seatbelt" (i.e. version control system), as it will only serve to help them "survive/not die" (i.e. not screw something up so royally, they spend the next two days rewriting something). Unfortunately, given the stubborn nature of man, this is not always true. As skydiving, bungie-jumping, driving an SUV, and voting republican (I kid, I kid!) have shown us, we have the uncanny ability to turn into the face of danger, and against all common sense and self-preservation, knowingly do that thing which will probably screw us over in the end.

The entry level barrier is quite low with a true seatbelt, it is about as minimal as it gets. While version control systems have a slightly larger barrier of entry, the returns on investment are on par with the seatbelt (see: not dying). Still I've found there exists a minority (I hope) of individuals that don't, or even refuse to wear a seatbelt, or in the developer world, use version control system. Convincing said individuals that a seatbelt, or a version control system, is a worthwhile investment is like shouting at a brick wall to change color. No amount of reasoning, or (un)common sense is going to sway their opinions, they all have their excuses so trying to convince them to do something in their best interest is futile to say the least. It's just not going to happen, ever (don't dispute me, I've tried, and the brick is still red).

"I don't need to wear a seatbelt, I'm careful and I drive very safely."

Accidents are never planned you nitwit, so just buckle up already.

[tags: versioncontrol, perforce, subversion, cvs, seatbelts]

04/10 sort of simple syndication

I just wanted to make it known that I've finally gotten around to "fixing" the RSS feed for this blog. It wasn't really broken, it was just a full feed, i.e. there wasn't an abbreviated version of the feed (with the first ~600 characters, for example)



[tags: xml, rss, nucleus]

04/10 my head asplode

As I think I made clear yesterday, I'm knee-deep in the middle of a week with more than its fair share of screaming "WTF?!" incidences, I'm writing today to report that, the number of such incidences is most certainly not going down. I can't exactly pin down who said it first, but one of my favorite quotes, paraphrased, is that give any (software in this case) engineer a simple, straight-forward system, and they'll be able to not only suggest, but implement an over-complicateed, over-engineered system on top of it, and thusly, completely miss the point.

The best code is the least amount of code, and if you don't agree with me, you're wrong (sorry). The absolutely most talented developers I have ever known are capable of implementing a concept, or a feature addition, in the smallest amount of code necessary, writing clear, concise code, with appropriate documentation as to what the code should do. In my opinion, documenting a class, an interface, or some function with what it is intended to do is far more helpful than anything else you can do, especially during the process of debugging the code, or optimizing it later on. It is far easier to explain that a given function is intended to chop up an arbitrary XML file and translate that into a new object that will more or less represent that arbitrary XML to the rest of the application (poor man's serialization), than to say, explain how you are chopping that XML up. I look at developing more or less as finding the means to and end, the implementation of any system should be irrelevant (provided it works of course) so long as the end result is achieved. There are several pitfalls with this philosophy of course, poorly written code being one of the major ones. If the code is absolutely unmaintainable, then the implementation most certainly does matter, mostly because of the nature of software, if it is not moving forward, it is dead.

Read the full entry »

03/10 this one's for my homies in the NOC

Some of the consulting work I'm currently enduring involves a client-server architecture and while I am certainly no Todd Manning when it comes to network programming, I can hold my own. My work deals specifically with the client end of the system, so I've been given the task of making something new work within the confines of the existing server architecture. Its not the easiest work, but seriously, how hard is it to mess up a client-server architecture in which just some basic XML markup is being transmitted and parsed between both ends? (Note: If you've ever worked as a commercial developer, I'm sure you just winced at that 'how bad could it be' statement I just made).

My recent work with bridging the gap between my client code and the server has led me to one of the most prolific questions I've ever had to ask myself (this morning at least):

How much pot would you have to smoke to believe a system in which two unidirectional TCP sockets are required makes more sense than say, a single standard bidirectional TCP socket?

Some of the possible motives I can think of being behind such a design are:

• "OMIGOSH TWISE AS FASTT!@!! LOL!!""
• "It's not like its a big dump truck..."
• "omg i luv to chat wit ppl and play video gamez, i shuld major n computer sceinces!!!1"
• "Ow ow ow ow, networking book hurts my BRANE!"

I just want to go curl up in a ball and cry.


Note: "NOC" is short for Network Operations Center

[tags: sockets, csharp, itsajokestupid]

03/10 LifeDrop, worth the time?

A few months ago, Fernando pitched me an idea for an application he wanted to create called "LifeDrop." Fernando wanted a better means of trackng blood sugar levels, as well as insulin units. Typically (from my understanding that is) most diabetics, provided they are doing as they should and tracking their sugar levels, use a very low-tech log book and a normal glucometer. Tracking things in a pen-and-paper log book is not only tedious, but it's certainly lacking some of the pizazz that a desktop application (LifeDrop) could offer.

One of the greatest powers of computers, especially in the healthcare industry, is one of data visualization. The ability to chart sugar levels, and insulin units on a graph over time can be very helpful, especially as it gives the user/patient a better idea as to what's going on in terms of their diabetes. Such an application would also give the user/patient the ability to export the data into other formats (PDF, comes to mind) to be transferred to a physician, some other healthcare professional, or, Dr. Mom. The benefits to the actual end-user of such an application are far to numerous to list individually, but once any set of data is in a malleable form (i.e. in the LifeDrop data store), the various means of manipulating, and visualizing the data are almost endless.

There's a catch, there always is; the only diabetic that I know is Fernando. Fernando's a super nice guy, its just...he's one guy, a young male, Mac-using graphic designer and not the best gauge for what sort of "potential market" LifeDrop would have. Given the sky-rocketing number of diabetics in America today (7% of our total population has been diagnosed with diabetes, with around 14.2 million undiagnosed), the number of computer-savvy individuals on the planet that could make use of such software is obvious, but the question is as to what number of computer-savvy earth-dwellers actually would.


Currently, the code is all in Cocoa, so its Mac-specific, but porting the under-pinnings to C# (via Mono) would be feasible, in order to make a Mac and Windows application. The question of developing the application is not a difficult one to answer, if I can justify the costs of development, and the need/demand for LifeDrop.

If you could develop an application that would at the very least help out a good friend, and possibly help a much larger number of people stay healthy, and on top of their disease:

• Would you charge for it?
• What features would you add to it?
• How could you legally protect yourself against the litigious healthcare industry if it came to that?

[tags: cocoa, lifedrop, diabetes, coregraphics]