Minor Technical Difficulties

We are currently experiencing some minor technical difficulties: Normal service will be resumed shortly…

Oracle, Google, Java, And The Courts

Yet another legal decision involving intellectual property from Friday; this time the appelate court in DC continues the 2012 suits between Google and Oracle regarding Google’s use of Java in Android. The original trial judge ruled Oracle could not claim copyright protections for parts of Java, and the appellate court reversed the decision:

“We conclude that a set of commands to instruct a computer to carry out desired operations may contain expression that is eligible for copyright protection,” Federal Circuit Judge Kathleen O’Malley wrote.

Which means the whole thing is heading to the Supreme court very soon. In the interim, every programmer who doesn’t have an array of lawyers lined up to review their code to ensure it doesn’t compromise copyright somehow/somewhere is going to be hurt by this decision. I hope the Supreme Court takes that cost into consideration.

Employment Collusion In The Tech Industry?

An interesting article over at Pando focusing on what seems like large tech companies conspiring to keep wages down.

Back in January, I wrote about “The Techtopus” — an illegal agreement between seven tech giants, including Apple, Google, and Intel, to suppress wages for tens of thousands of tech employees. The agreement prompted a Department of Justice investigation, resulting in a settlement in which the companies agreed to curb their restricting hiring deals. The same companies were then hit with a civil suit by employees affected by the agreements.

This week, as the final summary judgement for the resulting class action suit looms, and several of the companies mentioned (Intuit, Pixar and Lucasfilm) scramble to settle out of court, Pando has obtained court documents (embedded below) which show shocking evidence of a much larger conspiracy, reaching far beyond Silicon Valley.

On the face of it, this is a bad thing. Companies should not coordinate their hiring so as to keep wages low. And, yes, it does appear that they were doing this, based on an email from Eric Schmidt, CEO of Google at the time:

  1. Google is the talk of the valley because we are driving up salaries across the board. People are just waiting for us to fall and get back at us for our “unfair” practices now.
  2. Our recruiting practices are “zero sum” and it appears that somewhere in Google we are targeting EBay to “hurt them” and its the reputation that we are doing this against Yahoo, EBay and MSFT (I denied this.)

The good folk at Google go on to further incriminate themselves in writing before Mr. Schmidt notices “…I don’t want to create a paper trail over which we can be sued later?” Um, a bit late on that one. [here's a tip: If you're concerned that something you are doing might be used as evidence against you later in court, don't put in writing that you're concerned the very thing you are doing might be used against you in court]

Now, having said some of the reasons why this is a bad thing (and it most likely is), it’s also somewhat defensible. Some of these companies have formally partnered together and/or have other arrangements in place. Those arrangements are fundamentally political in nature (in that it’s about the relationship between the two companies, not Republican/Democrat politics). Hiring valuable employees away from your partner will strain those relationships. So, there is a sound business rationale for not poaching employees — a rationale that does not consider wages at all. Even though that is a likely and predictable result of these arrangements.

I’m glad that the government is taking a look at this (which is an odd thing for me to say, but there you go). It will be interesting to see what kind of balancing act is worked out in the end, trying to manage freedom of association, freedom of speech, contract law, monopoly provisions, HR law — lots of interesting stuff going on here.

Oracle Loses In Court Again. And That’s A Good Thing.

Following Oracle’s utter washout with the Google case (and you really should be reading Eric Raymond on Oracle/Android if you weren’t already), Oracle is on the losing end of a EU decision on the Doctrine of First Sale:

By its judgment delivered today, the Court explains that the principle of exhaustion of the distribution right applies not only where the copyright holder markets copies of his software on a material medium (CD-ROM or DVD) but also where he distributes them by means of downloads from his website. Where the copyright holder makes available to his customer a copy – tangible or intangible – and at the same time concludes, in return form payment of a fee, a licence agreement granting the customer the right to use that copy for an unlimited period, that rightholder sells the copy to the customer and thus exhausts his exclusive distribution right.

In other words, once you buy it, you can resell it, despite what the original seller may or may not want. Just like as if it was a physical CD; the medium doesn’t matter in this case.

Unlike the Google case, Oracle wasn’t particularly in the wrong here. Uncle Larry was pursuing the same licensing strategy that just about every other software company does. It’s just bad luck for their legal team that they were on the chopping block so soon after the Java fiasco.

Falsehoods Programmers Believe About Gender

Building off the time and names lists, here are a few erroneous assumptions about gender. All of these I experienced through both coding and working with HR systems in the US government, several corporations and a few overseas governments to boot. Since gender can be a touchy issue (particularly in the US), I’ve included examples for where one might think it to be questionable:

  1. There are two and only two genders.
  2. Okay, then there are two and only two biological genders.
  3. Gender is determined solely by biology.
  4. Okay, it’s mostly determined by biology, right?
  5. Please tell me it’s determined by DNA.
  6. Gender can be reliably determined through visual means. After all, no man would ever wear a burka.
  7. Once gender is set, it never changes.
  8. Even if the gender can change, it will only change from the one value to the other value.
  9. Only one gender can be “active” at the same time.
  10. We’re tracking gender now, so we’ve always tracked it.
  11. I only need to be concerned with human gender.

If you have suggestions or corrections, let me know in the comments and I’ll add them to the list.

“Unfortunately … they are faced with a question that no one has ever been able to answer: what is the ultimate difference between a man and a woman? This is not a solvable problem.” Alice Dreger, author of Hermaphrodites and the Medical Invention of Sex.

Speaking At BigDataCamp DC During Fose Tomorrow

Tomorrow, I’ll be giving a lightening talk at the BigDataCamp unconference during Fose. My talk will be an overview of NoSQL technologies, their respective pluses and minuses, as well as where they fit in the enterprise. Hope to see you there.

MapR, HDFS and Forking Code

I was in the exhibition hall of StrataConf talking with the good folks at MapR. During our conversation, the MapR rep said “we’ve rewritten HDFS to optimize it and make it better”. The rest of our conversation is (roughly) below:

Me: Okay, you forked the code. That’s going to raise some support issues, as you will be the only people who can support your flavor of HDFS, whereas a vanilla HDFS can be supported by just about anyone.
Rep: No, we didn’t fork the code; the API is exactly the same and everything works the same.
Me: So, you didn’t change anything in HDFS?
Rep Yes, we did; we made it better.
Me: Then you forked the code.
Rep: No we didn’t.

At which point I just walked away and thanked him for his time.

My question to the group is (basically) did I miss something? This seems like a pretty straightforward example of forking the code. Right?

Been Away For A While

Things over at RE are heating up. In fact, we’re probably going to be doing a soft launch (read here: an early alpha to select people) in the next week or so. If you’re interested in joining the list, send me an email and I’ll see what I can do for you.

Until then, here’s a cat picture.

we iz gonna take over the wurld Been Away For A While

That is what the kids like these days, right?

Idea Factory — Secure Garbage Collection

It’s a fact of law that when you put your garbage on the street, anyone can paw through it to their heart’s content. This can be a problem for two groups of people — celebrities and criminals.

General Concepts:

Offer a refuse collection service where the trash is not “thrown out,” but rather has its ownership transferred. At no point in time would the refuse be “on the street,” so no external parties would be legally able to access it.

Problems Foreseen:

  • To put it mildly, this would be rather costly business to start, between the capital requirements for the pickup process, the legal hurdles to be properly permitted and the like
  • Not a very large market of potential clients
    • Even those clients are generally spread unevenly across a large geographical region
  • It’s not just The Sopranos — waste management has a tendency to involve somewhat shady people
  • Unless you have some very spiffy technology involved, there is little barrier to prevent entry by the existing waste management companies.

Mitigations:

  • With regards to both capital and legal hurdles, there’s not much that can be done there; rent seeking is just a fact of life.
  • There may be geographical concentrations (Hollywood, perhaps); for ones that are spread out, either collect less often (once a week, every other week, etc) to lower the fuel costs and work in sectors or … yeah, I don’t know.
  • One of the thoughts I had on this was to create an RFID transmitter/receiver pair where the transmitter lives on the garbage truck and the receiver(s) live on the trash receptacle. When the truck pulls within ‘x’ feet, the trash can would unlock for disposal.

Day 0 At #GlueCon

Tuesday was sort of a pre-day for GlueCon. I flew out a day early both to try beating jet lag and to learn a bit more from the conference than I otherwise might.

Travel Fun

I flew on Southwest because, well, it’s cheaper. And I got what I paid for. The flight into Midway was fine, but the flight into Denver was bumpy. There’s nothing quite as relaxing as hearing the pilot announce “We’re going to have the flight attendants sit down for the rest of this flight. It’s going to be really bumpy, but we think we can get on the ground before the tornado comes through.”

Cross Platform Mobile Apps

The tutorial session I went to was on creating cross platform applications using Adobe Flash Builder and OpenPlug (now owned by Alcatel-Lucent). OpenPlug is taking the native route, turning ActionScript into device specific native code (as opposed to an emulator like PhoneGap).

I’ve been exploring cross platform mobile development environments (CPMDE) for the past few weeks on behalf of Resume Everywhere. I’ve come to a conclusion — these platforms are appropriate for prototyping and maybe — maybe — rending an MVP, but not much more. The scaffolding and accoutrements that go with these environments make the production support requirements unacceptable. A simple “Hello World” program built with OpenPlug resulted in a 3M Android app and 1.4M iOS app. However, OpenPlug has the bonus of being free.

The reason why I’m hesitant about using CPMDE for an MVP is that prototypes have a nasty tendency to turn into production releases. Based on my experiences with customers over many, many years, most customers tend to view a prototype as not only pre-release candidate but an explicit promise to release soon. Like the day after tomorrow.

Business Cards Aren’t Dead Yet

I’ve been spending lots of time at conferences lately. And one of the main goals is meeting people and spreading the word about Resume Everywhere. Usually, this involves lots of shaking hands and handing out business cards.

You might be thinking something like “Wow, business cards are so passé, not to mention bad for the environment. What about using some technological solution?”

There are quite a few companies trying to be the tech solution to business cards — Bump, Hashable, TwitCards, Card.ly — and those are just the ones off the top of my head. The general problem with them is that they make assumptions which often prove wrong.

  • Bump assumes both you and the person you want to give your card to (a) have a smart phone and (b) have both installed the Bump software. Smartphone penetration is remarkable in the US, but it’s hardly ubiquitous.
  • Hashable assumes you are both on Twitter. Twitter is fun and growing in popularity, but it’s still relatively very limited as to who participates. You can use email (which is pretty much ubiquitous), but the mobile app, website and pretty much everything about Hashable is geared towards Twitter.
  • TwtBizCards — see the first part of Hashable
  • Card.ly has the same pluses and minuses as its brethren (Magnt, Chi.mp, About.me) — it’s just a webpage where you can download a vCard. On the plus side, no special software or tools required, just a web browser. In the minus column, you’re expecting another person to download something; several extra steps that lower the chance of follow through.

There’s also the social mechanics of it. Compare this procedure:

  1. Find someone you want to exchange information with
  2. Determine if they have a smartphone
  3. Ask if they have Bump installed
  4. “No? What is your email address/Twitter handle?”
  5. “And how do you spell that?”
  6. Hashable connection made

as opposed to this:

  1. Hand over business card

bcard back 300x171 Business Cards Arent Dead YetPaper business cards will work for any person at pretty much anytime. If you want to high tech the paper card, put a QR code on it — that’s what I do. You can make a QR code that contains the vCard information within it or as a link to where the vCard could be downloaded. Such a code on a paper card can be scanned into a smart phone with a barcode app installed. Granted, that’s not a huge percentage of the world, but it’s a growing one. And, for those people you meet without a barcode enabled smart phone, there’s always the old fashioned way.

–Update–
Added the social mechanics section.

Tutorial Day At #RailsConf

Yesterday, Scott and I went up to Charm City to sit in on tutorial day of RailsConf 2011. It was a good enough day.

As I don’t know Rails — at all — I went to the Rails for Idiots track. Otherwise known as Rails For Zombies and a live review of the Ruby on Rails Tutorials book. Scott went to Building Web Apps With HTML5 and Rails Best Practices. As far as I’m concerned, I paid $170 for the Zombies class — which is free online — and a live walkthrough of the RoR Tutorial book — which is also free online. The upside is that being in the room forced me to take the time to do the class, as opposed to being at home, where my login to the Zombies class laid fallow for a few weeks without me even starting.

I can’t particularly complain about the Zombies class: I did learn enough about RoR to be able work the data side of our architecture in a way to better facilitate the overall product. The continual Zombie metaphor wore thin pretty quickly, but it least it was a unified idiom throughout the presentation. The tutorial, on the other hand, assumed a higher level of competence with RoR than I have, as well as a fully established RoR environment on your computer. So, that was a bit less useful.

Why Trying To Find A Technical Co-Founder Will Almost Always Fail

Last night, I went to a local “find a co-founder” meetup for RE. A while back, one of the original people helping get RE off the ground left to pursue other options (an amicable split, which is always nice). I went to last night’s festivities to see if there was anyone else suitable who could try and fill Mike’s shoes.

In general, the meetup was a pleasant surprise from what I expected. Based on several other similar events I’ve been through, I expected the ratio of business people to technical people to be somewhere on the order of 20:1 — and most of those business people would be of the “I have an idea and am now just looking for a techie to build it for me” variety. This particular meetup was probably along the lines of 3:1 and generally rather well ran; we had a lightning round were everyone introduced themselves and clearly stated what they were looking for. Which went a long way to simplifying the meet & greet that followed.

A number of the people I met were interesting and one or two may hold some promise, but it struck me that these events are pretty much set up to fail from the beginning.

[Read the rest of this entry...]

A Quandry With LinkedIn

So, I generally believe the people with which you connect on LinkedIn should be limited to people you know, work with and (usually) respect. LI is becoming more and more established as a means of social proof for both potential startup investors and potential employers. There are those who consider the people on LI who add four, five new connections a day an undesirable connection (#2 in particular).

My quandry revolves around Resume Everywhere. The customer base for RE is comprised almost exclusively of recruiters. And recruiters are promiscuous on LinkedIn. With that in mind, I’m coming into contact with lots of recruiters at various conferences, meet & greets and functions. Somewhere between 40-50% of the recruiters I meet this way want to connect over LI. So, do I accept in order to try and build the business? Or decline and keep my “social proof” purity score high?

Reason #1453 Why I Don’t Like Apple’s Mobile Platform

I’ve said this many times before (and it looks like I’ll be saying it again) — Apple’s iOS platform is a walled garden. Just like Facebook now and AOL before it, you can only play in the garden if you follow all of Mr. Jobs’ rules. And if they change the rules? Well, you can stay and suck it up or you can take your ball and go home. Those are the only two choices you have.

The latest victim to the every changing whims of Cupertino is iFlowReader. In their open letter, they announce not only why they are ending the app but are closing the entire business (the letter and my thoughts after the jump):
[Read the rest of this entry...]

Returning To My First Love

Not literally — I’m still quite happily married. I started playing drums when I was six years old. My older brother begged and begged and begged our parents for a drum set and he finally got one that Christmas. Granted, at six I wasn’t Buddy Rich or anything; it took me probably a year or two of banging around to start and get the hang of coordinating both arms and one foot in a repeatable fashion.

When I was growing up, I would probably play drums for an hour or two a day, every day. It’s a great way to work out stress and anxiety, and what could be better for an angsty teenager then working through both real and imagined problems by pounding them out in 4/4 time? Throw in the fact that if you started drumming in the 80′s and came from a rock music background, and you were pretty much issued Rush cassettes as aspiration goal fodder. Neil Peart is a high bar, but a good one to shoot for if you’re just learning. And, yes, I am one of those drummers.

Things continued like this until I was 19 or so. I didn’t have room at college for a kit and I wasn’t home enough to justify keeping it with my parents, so my old set ended up being given away to a cousin (hope you enjoyed it!). After graduating, I never lived in a place where the people living in the apartment below would appreciate the kick drum impact overhead for a few hours a day. But that’s no longer the case. So….

Yesterday, I went out to a local music store and picked up a used Roland V-Drums TD-20. Sure, I could have gone with acoustic drums — and, let be honest, there is a very big difference in how things feel on an acoustic kit versus an electric one; the cymbals as a main indicator — but the electric kit fits better with my personal life these days. The ability to play softly while full sticking is a nice plus, particularly with two small children.

I’m way out of practice, but the first 30 minutes I took sitting behind a kit was like going home again. I had forgotten just how much fun it is to play and how good it felt. It’s nice to be home.

Idea Factory — Smartphone Cloud Recording

The other day, I saw a news release from the US Department of State about their panic button app intended for pro-democracy protesters in foreign governments to be able to wipe the contacts from their smartphone and prevent the government agents detaining the protester from gaining more intelligence about the protester’s social network. A good thing, and one I support.

But what about something not quite so dire? What if you were being pulled over by a police officer for being in the wrong place at the wrong time? Or if you were in a potentially compromising situation (say, a male senior manager alone in a room with a significantly more junior female employee who you’ve just terminated and who has offered to “do anything to keep her job”, just as an example of which I am personally aware [just to be clear, not me --ed])? Or out on a date with someone while you’re riding in his car and you just get that “something’s wrong here” feeling?

[Read the rest of this entry...]

Six Priorities Of Traditional Software Development

When designing and developing a traditional software system (i.e. one that will be installed on an end user’s system, rather than running in the cloud), there are several design goals for a successful project. These goals are:

  • Availability of the system (Availability)
  • The ability to backup and recover the system (Backup/Recovery)
  • The ease of use of the system (Ease Of Use)
  • The performance of the system (Performance)
  • The amount of resources used by the system (Resources)
  • The overall security of the system (Security)

As laudable as all of these goals are, they will compete and conflict with each other from time to time as to their relative prominence within the design. For example, while it is possible to create a system with “perfect” security, it would be so impossible to use that no client would ever accept it. Accordingly, here’s where I generally place these six design goals in the following order from most important to least important for traditional software development:

  1. Ease Of Use. If the system cannot be put to use easily and quickly by the end users, they will abandon it for another system (or collection of systems) that will accomplish their task while making their jobs easier.
  2. Availability. If the s ystem is not available for use, the end users will not be able to use it, no matter how successful the team has been with priority #1.
  3. Performance. If the system does not respond to the users’ requests in a reasonable amount of time, they will look for alternate means to accomplish their tasks.
  4. Security. If the system cannot maintain the confidentiality of the user’s data, they will not use it.
  5. Resources. If the system requires exorbitant resources, the customer will not buy it.
  6. Backup/Recovery. If the system is difficult to backup and/or recover, the customer will have to allocate additional resources to address that shortfall.

Obviously, these rules are more oriented for a consumer market where the end user controls the decision making process. For other environments, a corporation can mandate the entirety of the users must use a given product, regardless of whether or not the new product is easier to use than the existing system. Alternatively, other organizations may place much higher priority on design goals which I have placed lower on the list — for example, groups like the US DoD or an intelligence agency may place security as the most important design element and all other elements have to comport with the security restrictions. The individual needs of a customer’s project may cause the list to be reordered as appropriate to the business needs. For example, if developing software for mobile devices, the necessary constraint of the hardware environment will cause Resources to become a higher priority for the development effort.

How Resumes Are Stored

If you are a job seeker and you go to most job boards these days, you will be asked to do one of three things:

  1. Enter your resume information section by section
  2. Upload a file containing your resume
  3. Open your resume in some other program (Word, vi, Pages, et al), then cut and paste the resume text into the appropriate section on the web site

All of these approaches get the data into the resume database, but some of the approaches are better than others.

  1. Entering resume data piece by piece is tedious, but it results in clean and neatly segmented data. Which is quite helpful in making sure that your resume appears in search results in the best way possible. From a data management perspective, this is the preferred approach; not so much for the job seeker.
  2. Uploading a file has the advantage of being quick but is also quite dirty. In general. it’s a bit hard for the website to break out the data in a regular and repeatable fashion. This is particularly true as quite a few people use their own personal and unique style of organizing data. If you’ve ever uploaded a resume and wondered why the name of your university became “Sept 2004-Dec 2008″ instead of “UCLA”, you’ve run afoul of an automated process tripping up on the format of your resume.
  3. The worst of all worlds: first, the job seeker is required to take extra steps to open her resume and then manually copy the data into the website. Next, the website still has to work on dividing the resume text into meaningful groupings — this time without the helpful assistance of format cues embedded in the resume file from option #2.

Parsing

Well, the overall process is generally the same, but the specifics depend on the specific format of the file. All resume processing sites parse the resume file, attempting to allocate the resume data into neat buckets — this block of words are all associated with the work experience at firm “X” during dates “Y”-”Z”, but that block of text is about the time spent at university “A” majoring in “B” from date “C”-”D”.

Depending on how the document is formatted, the format itself — particularly with an XML variant like .docx — may contain clues within the structure of the data relating to the content of the data. In other words, metadata. While the generic overall schema specific to .docx (the MS Word format for Office 2007 and later) is not even vaguely resume oriented, the general convention amongst most resume writers is to use various formatting options (bold, italics, underline, white spaceetc.) as signifiers for changes between resume data elements.

Pretty much any format into which a resume can be saved can also be parsed. Some formats (text, docx) are easier than others (PDF, I’m looking at you); in general, it’s a matter of how much work it will take to find and correctly identify the sections of data. In the next post of this series, we’ll go into further detail for the most common resume storage formats, their associated pluses and minuses and other assorted details.

This is the first of several posts about the technical details on how resumes are commonly stored in the online world.


Originally posted on Shuffling Paper, the RE blog.

It’s Been 7 Startups

When people ask me if Resume Everywhere is my first startup, they are surprised at the answer. Not the fact that I’ve done startups before; rather, that RE is my seventh. Yes, really — 7. Here’s the breakdown:

Company Product/Service Dates Result
Best! Software Shrinkwrapped Fixed Asset Depreciation Software 1995-1996 Acquired by Sage Software in 2000 for $445M
Convergys Leased Land Line Management software 1996-1997 IPO August 21, 1998; still trading
Exigent Satellite Ground Control Software 1997-1998 Acquired by Harris in 2001 for $23M
Integrated Chipware Requirements Traceability Software (RTM) 1999-2001 RTM Acquired by Serena Software in 2004 for $3.8M
Secure Telecomm Innovations Network Encryption Software 2001-2002 Closed down in 2002 due to lack of funds
Realeum Cloud-Based Apartment Management Software 2002-2002 Acquired by First Advantage Corp in 2004 for ~$2.5M (at least, that’s what I glean from the filed 8K
Resume Everywhere Resume Synchronization Service 2010- Well, I suppose we’ll see…

This is not to say that I was the driving force in all of these companies — for Best!, I worked tech support and QA. But I believe I learned quite a bit along the way of what to do and (probably more importantly) what not to do. And, for better or worse, RE is the first one in which I’m ultimately responsible for the whole shebang. It’ll be fun, I think.

I used to characterize my startup experience as one success (Best!), two break-evens (Convergys & Exigent) and three craters. Now that I lay out things in the above table, it’s not as bad as I thought it was. IC and Realeum both go in the loss column, but they weren’t complete failures; at least some money made it’s way back to the investors. STI, on the other hand, was pretty much an implosion. It’s where the 5 Guys From DuPont rule originated.


Most of this post originally appeared on Shuffling Paper, the RE blog.

RE’s 2nd Pivot

Since Mike has moved on and Scott and I have been looking for a replacement, we have also been closely evaluating our current business and technical model. At this time, we no longer believe it to be feasible within our current level of resources to pursue resume synchronization; we will be changing our focus and moving down the ATS route.

Be warned, this is a bit of a long post. I’m writing it to explain what is happening, why it is happening and what to expect in the future both to everyone already involved with the project and to the other people who had signed up to try the service but had not yet gained access. More after the jump.
[Read the rest of this entry...]

Get Adobe Flash player