Archive

I added a book list here. Heh.. filled up the max capacity of the list component. Had to drop about 20 old books just to fit the new books.

Don’t worry, I’m not stupid enough to believe that my worth is wrapped up in my books. The books are definitely assets–I read them, they give me skills, I make more money, a net residual income effect–however there are more words in all these books combined than I could possibly digest in what tiny little bit is left of my young adulthood. So I keep them handy as references until I need them.

That said, I do want to get back into reading the newer books cover-to-cover. If I manage to do this I’ll certainly try to blog about it now and then.

Update: I hid the list for now but I’ll re-enable it once I have more meaningful content. Nobody cares about a list of books anyway but if for some reason you do, you can still find it in the Lists link at the top left.

A salt is used in cryptography to make decryption less efficient for attackers by adding another hashing layer on top of an encryption algorithm. When a passphrase is used to encrypt data, a salt can be additional data that gets concatonated to the passphrase or key. This means that the attacker’s dictionary now needs to contain many more entries, one for each possible salt value for each probable passphrase.

Salts are implemented as random bits. They are used as a second argument along with the passphrase in a function that is used to derive a decryption key.

For practical purposes, you can use salts as a second passphrase equivalent across services, such as for example when interfacing with a third party web service that intends to be synchronized. By agreeing upon a common salt or salt algorithm, such as making it time-based, you can support handshaking while retaining an extent of cryptographic security.

For more information, the following Googled links are just a tiny few of the resources that describe salt in the context of cryptography and some of them provide a good introduction to cryptographic principles:

So Panasonic has a 103" plasma television for sale for only $70,000. This reminds me of the yacht size competition that’s been going on between the planet’s wealthiest folks who are out to sink each other on the basis of size alone. It’s such a rediculous waste of money. Think about how many starving children you can feed in Africa for $70,000. I’m thinking, for one day, about 140,000. For life, about three.

I just realized, I could buy not one, not two, not three, but ten 2002 Toyota Echo cars. I love my 2002 Toyota Echo … Maybe the other nine would be back-ups in case the first one needed an oil change. Or I suppose there might be ten different colors, one to match my clothes for the day, but I don’t think they had that many colors for the car. Hmmm….

I read an article the other day in InfoWorld that made me want to vomit. The author made me sick. He was whining and complaining about those despicable recruitment agencies that go through job candidate listings like real estate listings, yet his own frustration was with the clients, the companies that hire people for six months to do impossible feats and then just let them go. Namely, these were temp-to-perm positions that he despised. Contractors would sell their soul to a company, being on call with a cell phone through the nights and weekends, doing everything that they could to win the favor of the employer well enough to keep going on a permanent basis, but then be let go as soon as the so-called "probationary period" was over. These companies, according to him, were abusers of the system, taking advantage of folks who really wanted a long-term position by convincing them to bend over backwards for them and then letting them go as soon as their commitment ended.

I think the author had an attitude problem, for one thing. And I think the author’s attitude problem showed in his personal experiences with these temp-to-perm employers, and I think that’s why he didn’t retain the positions. But what bothered me most about the article was that he made a very pronounced notion that short-term contracts were for people who were spoiled by the dot-com craze of the late 90s and for young people. That was frankly insulting, because I see a lot of value in short-term contracts, both for myself as well as for employers, and the dot-com jumpstart of the Internet was not a regretful mistake of the economy but an overzealous surge of interest in a new thing. If there was a mistake in the late 90s it was in wasteful venture capitalism, not in hiring short-term contracts.

But the article along with my present state of unemployment did bring about the important necessity of discerning what the merits are of contracts, temp-to-perm opportunities, and permanent positions. To say one is better than the other is just ignorant. The reality is that they are very different, and address different needs of job candidates and of employers.

Standard Contract Positions

Contract positions are your typical three or six month jobs where someone would go in, do some work, and leave, and they would be paid for their time on an hourly basis. If you work overtime, you get paid overtime. You don’t get taxes withheld, you get 1099’d and are expected to pay taxes at the end of the year. These are scarce anymore for some reason, unless you have created a corporation for yourself and an EIN rather than a SSN is used on the 1099.

The advantages of a short-term contract is that you are not obligated to show loyalty to the company. You’re there to do a job, you might walk away with a professional reference, you gain exposure to a new environment with a new business and technical scenario, and you gain more experience in rubbing shoulders with complete strangers. Those may not sound all that ideal, but believe me, they grow you as a professional. Contracts typically pay out a little more for the hourly rate than permanent, salary-based positions simply because the temporary nature of the job is anticipated. Contracts are an advantage for hiring companies, as well, because they facilitate short-term needs rather than permanent ones, which is understandable in the world of software where, in the ideal world, software should be called "done" once written.

The disadvantage of standard contract positions is that you are extremely likely to be unemployed at the end of your term. This is a devastatingly frightening proposition to many people, especially for "breadwinning" family men having a wife and children. But for someone in a metropolitan area who has managed to maintain the lifestyle that suffices in demonstrating a strong grasp, both deep and wide, of the technologies and concepts and who has the soft skills to go along with the hard skills, the transition is usually short-lived. Just dealing with all of the opportunities can be a full-time job in itself.

The advantage of a short-term contract that is specifically on a 1099 basis is that you do get paid more because taxes are not taken out, but then you are responsible for your taxes.

The disadvantage of a short-term contract that is specifically on a 1099 basis is that the opportunities are scarce without an EIN. The IRS throws a fit when a SSN is used on a 1099, even though legally it’s perfectly fine and the IRS actually can’t do anything about it other than whine.

W-2 Contracts (Agency)

W-2 agency contracts are a strange hybrid of full employment and short-term contracts, yet surprisingly these are a common form of contract positions. These, too, are typically six month positions for a company that essentially contracts out the employment agency rather than the candidate. You might receive a salary, but regardless you probably still track your hours. Meanwhile, the employment agency then withholds taxes and hires you as a consultant, even though you never talk to them or see them or hear from them again except on your pay stub and perhaps every month or so when they call you up to ask how things are going. Actually, with these more than the standard contracts where an agent would just win a commission, you are typically treated with a lunch once a month rather than just a phone call. I’ve had at least one of these types of positions.

The advantage of W-2 agency contracts is that the negotating is completely transparent between the candidate and the company. You’re assessed for what you bring to the table, but the real relationship that the company has is with the agency. Legally, the agency is obligated to reimburse you for overtime because you are performing tasks that are commercially measurable, hence billable, by the hour (if indeed that is the case).

The disadvantage of W-2 agency contracts is that your real employer isn’t the company you’re working for but the agency. You are "owned" by the agency. You feel disconnected with your managing supervisor because even though they interviewed you, they didn’t actually hire you–they hired your agency and your agency hired you. This may not seem to matter at first, but will be felt, both in the interview process of developing a relationship with an agency as well as after you have worked with the company for a few months.

Temp-to-Perm Positions

I haven’t had to deal with any temp-to-perm (contract-to-permanent) positions so I don’t know what the relationship is on paper, but in practice these are "try-before-you-buy" options for employers. Yes, I did say "for employers" and not "for employers and candidates" because most job candidates have made up their minds that they want a long term job or a short term contract. A temp-to-perm position is begging for someone who wants a long term job but isn’t given any hope of being treated as a real employee until the contract ends. Negotiations are almost always consisting of the employer saying, "We want a permanent employee, but to start off with you will be a contractor." To that extent, the author of that article was absolutely right. And typically an employer who opts for temp-to-perm rather than either temp or perm is likely a difficult company to win over to patiently work with a candidate on a permanent basis anyway. It’s easy after a few months to find faults in someone, and it’s easy in that short a time period to quickly and heartlessly say "goodbye". People don’t usually grow from their jobs and prove their adaptability in a new environment until after a year, and that includes a company’s ability to adapt to a new personality in a team.

The fact is, any permanent position can typically be terminated in six months. You don’t need to go "contract-to-perm" for a company to retain the option of firing an employee or for an employee to retain the option of quitting. The whole notion here is to intentionally retain the intent to keep the position unstable.

Permanent Positions

Permanent positions are almost always on a W-2 basis. As an employee, you are "owned" by the company. These days, the employment contract is typically such that you can quit at any time and the company can fire you at any time, for any reason, stated or unstated. "Middle-men" such as agencies are much less likely to be involved in setting up a candidate for a permanent position, but when they are involved they typically win only a finders’ fee.

Permanent positions, the classic form of employment, are ideal for folks who need job security. I think they’re also very ideal for entry-level positions because they grow the employee at a personal level.

The downside of permanent positions is that they tend to be tree-hugging opportunities. People age with companies and it becomes difficult to keep up with technology because the surroundings don’t change. As a result, these positions are quickly becoming obsolete in the fast-paced world of software engineering. They are more reserved for IT support staff and for consultants.

Conclusion For My Life

In my view, the best option among these for a software developer really is the standard or W-2 contract. There are enough technical opportunities now that, short of the return of Jesus Christ or a nuclear attack or natural disaster that wipes out all computing infrastructures in the nation, there will never be a lack of new opportunities for software developers who use modern toolsets. Unlike other jobs such as manual labor, the more technology replaces our everyday tasks, the more dependent we are on people who implement the automation.

And it doesn’t make sense to just commit to one company for a long term when that one company will only have its own proprietary implementation to grow you. Diversity in experience beats tree-hugging loyalty, hand over fist.

This is not to negate the value of company loyalty or the wisdom in having a long-term, "permanent" position. Kudos to all breadwinners who are proud of themselves for holding out through thick and thin with their employers in order to keep food on the table. The insults that we "young’ns who aren’t married and go from job to job are just immature kids" are pretty difficult to take seriously. The trade-off of choosing a wife and kids over an exciting and diverse career of working with many different companies is perhaps there for many people, but declaring the superiority of one over the other isn’t particularly fair. I choose my career path to pursue a future of seniority in my field and thus to prepare myself for a future wife and kids. I look forward to cashing out. But I also know that once I cross that line, I won’t likely ever be able to go back. So why cash out too soon? Let the eggs mature before letting them hatch. That’s what a lot of these people failed to do, and it shows by their lack of understanding of industry knowledge with modern toolsets and skills. Personally, where maturity is a measurement of wisdom, I think the mature option is to not get too old too fast. This is a fast-paced industry and if you want to invest in it you have to keep yourself headstrong.

That said, would I consider a permanent or even a temp-to-perm position? Of course I would! I will consider any position that will grow me as a professional. If a permanent position entails a lot of growth in areas where I am lacking, and if that growth would require a very long term commitment to get past the hurdles, then I love a good challenge! And of course if a permanent position is one that I would love anyway, I may as well do what I love.

I am only trying to set my own expectations, not make a hard and fast decision for my next and future steps. Every opportunity should be considered as each one promises to bring a new set of experiences to my life.

Technical interviews can be so stressful. Any interview can be stressful, actually, but you can really get grilled in a deep technical interview. It’s always interesting when an interviewer starts off with technical jargon and asks you to explain what various terms are. These can actually be a lot of fun if you know your stuff.

Ironically, the interviews that fail to turn out a job for me have often been due to missing components of the job description. For example, I was once turned down for a lead web developer position because I didn’t have Google-class search (with relevance and prioritization) experience and detailed CMS (content management solution) experience under my belt, but nowhere in the job description were these to be found. But it didn’t matter. What killed the interview is something that they didn’t say. I blurted something about being willing to make certain compromises in my career path to make up for the career derailment of my last position. What a stupid thing to say, particularly considering the position wouldn’t have been a compromise at all.

What interviewers don’t tell you in follow-up interview responses (telling you you’re not wanted) is that you probably could have taken the position and your weaknesses overlooked if your personality matched, or if you were a little more confident, or if you didn’t word your answers in quite that way. Certainly solid responses are important for technical questions; you need to know your stuff if you’re a technical person. But beyond that, how do you respond to stress? How did you handle issues with your previous manager?

Every time I walk away from an interview, I have a list of items where I knew I "blew it". I write them down. I ponder them. I research better answers. I am not the first person to be asked these questions, and people out there have dealt with tough interviews. They have shared their experiences. And the Internet is a worldwide community where people can share those experiences. There is much to glean from.

So despite a couple rejections, I don’t come out at a loss. Nobody likes the lonely and sad feelings that result from rejection. But I strive hard to come out feeling even more excited and sure of myself as well as knowing what to say and, equally important, what not to say.

I knew about this already but this has me thinking. Over the last year and a half I have been working heavily with a CRM product that supports dynamic deployment of application plug-ins via a database BLOB record. The plug-ins are "self-contained" in that they introduce scripted content, not binary content. This is changing with the new release, however, which supports .NET Extensions.

One of my disappointments with .NET Extensions, however, is that .NET is not appropriate in the COM-based world that the product is. VB6 COM DLLs are far more appropriate. But the problem with VB6 COM DLLs is that they must be registered. That fact has caused the product development team to hesitate with supporting custom COM DLL deployments (except in very special circumstances, namely the OLE-DB provider extensions).

So I have a little pet project in mind that I might consider tackling. It consists actually of two components:

A command-line tool (with an optional GUI front-end) that will take a COM object, push it through the .NET SDK’s RCW generator, but then wrap that output (the COM object and its Interop file) into an "auto-install" assembly, embedding the COM object as a resource. This containing assembly would then auto-extract and expose the COM object through the CLR.

Another command-line tool that will take a managed assembly with its CCW and generate a native DLL with the CCW-wrapped managed assembly embedded into the DLL.

Someone at my former place of work (a certain S. Carnie) came up with an astounding solution after a few nights’ work of not only making a C# / VB.NET managed assembly a true COM object by wrapping it in a C++/CLI DLL–but also packaging up all the dependencies of the managed assembly (even the debug database!) and stuffing it all into one DLL for easy deployment. When a COM client calls upon this wrapper, the embedded resources are extracted and loaded and then called upon. This is why I love software!!

The catch with his solution is that AFAIK (I still have not examined his public source code) the COM interfaces were predefined. I would want to accomplish the same thing but not make them predefined. Essentially, I would want all public members of the CLR assembly to be COM-exposed in the native DLL.

This would likely entail some code generation and auto-compilation, in which case it wouldn’t be a small project. Even so, I know it’s doable, and I tend to wonder why Microsoft didn’t already do it.