2013/03/21

An Aesthetic All Their Own

As a part of developing iOS apps, you inevitably need to have an iOS device.  This isn't a problem for me—quite the opposite.  But I found myself in need of a new 4" form factor (I have been just barely resisting the urge to own an iPhone 5), and more I needed it in addition to my other devices (this app requires testing with multiple devices in unison).  So it was off to the Target to get an iPod Touch 5th gen.  But this isn't really about the iPod Touch or me unboxing it, but more how I was just struck by how much Apple is Apple, and they seriously don't care what Samsung is doing.

The iPod Touch can be summed up with one word: thin.  The device is so thin it almost feels like a toy.  This is the third touch I have used and developed with, and I'm just astonished how thin they have gotten these things.  But when I was hooking it up, I was suddenly stuck by the fact that the device isn't thin, it's the "whole package".

Lightning connector?  Super thin.  USB connector on the end of it? Barely bigger than the actual metal connector.  Have you seen the little pop-out so you can attach the silly wrist-strap to it?  Seriously?  Who puts that much work into jamming something like that into a device that is so thin it feels unreal?  Everyone else just puts a hoop, a post, or an indented slot for a wrist strap.  But oooooh no, not Apple.  We have to have a little pop-out button that sits flush with the unibody case that is actually better than most competitor's functional buttons for the phone or music player.  For the wrist strap!  Something almost no one is really going to care about or even use heavily.

Everything about the iPod Touch and its daily experience (like charging it) is thin.

Now why am I bringing this up?  Simply because I'm seeing a lot of (professional) opinions in the press that Apple must answer Samsung and must start looking at larger screen sizes beyond the iPhone5 and must do this and that too.  I'm sure many would point to the 4" form factor as proof that Apple feels the pressure.  But I look at the 4" and I see Apple responding to a trend, but doing it their way.  Note that it is still not wider.  And I highly doubt it ever will be any wider.  Why?

Because Apple likes it this width.  It suits them.  It looks aesthetically right to them.  I bet going to the 4" factor was hard for them.  I bet they thought it should be getting smaller, not bigger.  Lay an iPod Touch 5gen or iPhone 5 on an iPhone 4, and you can see they made it only a little bit bigger.  They like the size and feel of the size.  It feels right to them.

So Andy Ihnatko switched, and one of those reasons is he really likes the size of the Android device screens.  I'm sure there are a lot of people who agree with him.  Me, I like the extra space in the 4", but I'm still not sure I like the increase in carrying size.  What I'm saying is, I totally get the argument and people saying they like Samsung's Galaxy Note for its size.  For some, more screen space is a very good thing.  They then turn to Apple and say, "well?"

And the answer is probably going to be, "Yeah?  What?"  Because in the end, Apple makes products they like that fit their aesthetic.  They like what they make, and they think you will too.  And while they'll occasionally do something that seems very "market responsive" like increasing to a 4" form factor, they'll inevitably do it their way.  Because they like it their way.

Again, why make the USB connector so small?  They already had presses and stuff for the other size.  And the other size was already nice, shiny, and compact.  Because they liked it.  It was worth it to them to retool both the lightning connector and the boring old USB connector end.  Who does that?

Apple.  Because they like it that way.

I'm not saying it's better.  And honestly, I'm glad Android's out there to give them a run for their money in terms of ideas and innovation (although, as much as it may surprise some, I think MS did better with Windows Phone and tiles).  Android and the others keep Apple from getting complacent.

But in the end, Apple is going to respond in their own timing and according to their own aesthetic.  It's what makes Apple Apple.  And telling them how they need a low cost phone or they need a Galaxy Note ... well, they aren't listening.  Or that's my take on it.


2013/01/29

Security: The Big Misunderstanding

I was driving to get my haircut today when I had a really good idea for a collaboration.  That is, I thought of someone I knew and an application system I could write for his current job.  And then I started running through all the permutations of what could and couldn't be done, and then I thought, "Crap, there's no way I can get this app off the ground. How do I explain the limits of what we can and can't protect against?  How do I explain the security implications without sinking the whole project?"

Now this is where I have to admit that I already know there are at least 3 systems like the one I'm proposing out there.  They are all web based, and all of them let users access the system from home—without special security tokens.  I'm pretty sure none of these are more secure than my proposed application system, and I'm pretty sure (based on feedback from people who used the other ones) that they are less secure.  But I think security is kind of important, and I don't want to misrepresent.  My squeamishness over misrepresenting technical limits is why I wasn't the best consultant in the past (that's a joke, I love all you consultants out there) :-)

Also, I'll admit I'm not a security researcher or expert.  I'm not the magician of Hackers or Swordfish, and I can't crash remote systems by whistling.  I write software to be used, and this means that I bump up against the realities of trying to secure large and small scale systems.  So I know a thing or two about securing systems and applications, but it's hard to figure out how to explain this stuff to people who don't bang bits all day.

The thought that stuck me today is that people are using the wrong mental image or metaphor.  They are stuck looking at the physical artifact, but they fail to understand what's really going on in that physical artifact.  Without that special knowledge of what's going on in the little black box, they just use the best analogies they have for similarly sized objects.  Consider ...

Here stands a box in an office at Acme Wingnuts. It is the corporate file server.

Let us start by considering the flawed analogy, metaphor, or mental image that is used by 90% of the people who use this file server.  Now, you're probably here because you are a techie, so you need to take off your techie hat.  Regard the file server as someone who just uses computers and treats them like their TV or DVD player: to them it's a piece of technology that does stuff when they press buttons.  To this person, the file server is like an electronic filing cabinet.  Perhaps they are a person of particular imagination, and they realize you can cram a lot of information on a file server.  So they might even think of it as whole room of filing cabinets, perhaps a whole floor of filing cabinets.

Now, using that analogy, how do you prevent people from messing with your files?  You lock the file cabinet.  You lock the room the file cabinets are in.  You put a keycard on the entry to the floor to the rooms.  Or, if you need really good security, you do all three and have a guy who likes donuts (but works them off quickly with a daily gym regimen) patrol the halls and rooms.  Simple.  Problem solved.

Ok, so, if you are a techie, what's wrong with this analogy?  It's pretty simple: a Unix or Windows box is not a file cabinet.  Oh sure, we use it like a file cabinet, but that doesn't mean it is a file cabinet.  If you have done any small amount of system administration or tweaking of a home computer, you know that your computer has a lot of “moving parts”.  It takes a lot of software properly configured, running in harmony, to make that file server work.

The best analogy I could think of was to kind of “pull a TRON”.  Take the file server.  Now expand it into a contained entity with geography and complexity all it's own.  Give conceptual representation to all that is going on under the covers.  And since we are talking about security, I think a good analogy would be a military base.

Consider a military base.  It has information stored in files somewhere.  It has an established protocol for moving files on and off the base.  There are roads with gates, and those are manned by guards who check papers.  But for the gates to mean anything, you need fences—probably some pointy wire on them to dissuade intruders.  But you can't just run a base on filing cabinets, barbed wire, roads, and gates.  You need to have guards.  Those guards need housing.  You need to provide food, you need someone to take out the garbage, etc.  That is, you need more than just one building, and you need more than just one guy running the place.  Suddenly you have all this infrastructure just to wrap some filing cabinets.

Now you are all set.  The file server is not a small object that can be locked away, it's a huge military complex with tons of things going on and weekly shipments of ham hocks for the troops coming in.  If someone asks you why it is so complicated to lock down the file server, just refer them to their favorite spy movie.  In every one of those movies, the key plot point is that there's always a way in, no matter what the installation.  You can make it harder and harder to find a way, but that never makes you immune.  Just watch the Bourne Identity or one of those Mission Impossible movies where Tom Cruise is leaping off buildings and whacking guards with super-gadgets.  Heck, Mulder somehow got into that super-secret base to find out when the aliens were coming back, and he's just FBI!  If someone is skilled enough, has enough resources, or is obsessed enough, they can get to your data if given enough time.  It's all about making it hard enough to make it not worth their while.

And this applies to any computer system we use today, whether it's a large scale network or the iPhone in your pocket.  There isn't any such computer system in use today that is not on a network, that doesn't exchange data with another system, even if mediated by physical media (oh, Columbus Day Virus, what a surprise you gave us when you piggy-backed on my floppy I used at college).  So you have an analogy that helps make the reality easier to understand.

How can some script kiddie get our financial report through a weird email to Steve's computer?  Go watch your favorite spy movie, the part where the guy uses flaws in the building's security and gaps in the guards' patrol to get the super-secret-gun-thingie.  Your computer is like a complicated military base with layers of securities and safe guards, but a clever opponent can trick some, break others, and use others still to get to his objective.  The computer we read emails on is not a simple TV, it is a complex system running hundreds of processes and programs, each with weak points that might be exploited by a clever spy.

Which is to say, unless it's buried in concrete, dropped in the ocean, and turned off, there's no such thing as an impenetrable system.  If you insist on using it for something, and heaven forbid, being able to access it from another computer—worse, over the internet!—you are going to have risks.  It's all about mitigating the risks sensibly while still having a usable system.  A tough balance, let me tell you.

Back to my starting story, I figure I'll still pitch the idea.  It's a useful idea, and I think it's worth the risks—properly mitigated, of course.


2012/06/09

Don't Mind the Dust

I'm working on getting the blog template sorted.  We are currently using a more modern (yet generic) template from blogger.  I'm hoping to get something that matches the current site design soon.

But then again, I'm kind of busy.  You know, writing software and such.  So no promises ;-)

2012/06/05

Let's Do This Thing

It's a Micro-Startup

Here's the thing.  I have an idea.  It's an app.  I'm going to write it.  Then I'm going to put it on the App Store, and some of you kind folk are hopefully going to buy it.

I've done a lot of due-diligence on the idea.  In the end, I have my little charts and my projections on sales and return.  But in the end, none of that really matters.  Because this is a micro-startup.

Startups—what's are they really about?

What are startup companies about?  Anymore, it seems to be about making loads and loads and loads of cash.  Being the next Facebook.  Or better, the next Instagram or Meebo who gets bought by the big guy for gobs of cash.  

That's what all the news is about.  But let's take a step back from that and ask ourselves which comes first: the burning desire to own our own little island or super-yacht, or the "great idea"?  I won't try to be silly here and claim that it's always about a great idea and money is a secondary thing.  But all the truly great companies start with a great idea and are based around a great idea.  Oh sure, there's always dreams of happy little bags of money dancing around in their heads at some point or another—and quite usually right from the start.  But it's always about some "great idea".

*That* is your "great idea"?

One person's great idea is another person's stupid idea.  Some people might even tell you upfront.  Probably not your mom though—she's always been your biggest fan.  But the reality is that in the end, some people are going to think your idea is pretty dumb.  But that's just some, so take heart.

No, only a few people in the end will think your "great idea" is stupid.  The vast majority, however, will likely just shrug and say "that's nice ... did you see the game last night?"

Here's the thing: it's your idea.  You thought it up, and then it rattled around in your brain, and you very quickly started to think, "Wow, that's really pretty cool.  I wonder ..."  And then you were thinking about what might come next or how you might do it.  As you thought about it more and more, you grew more and more excited.  This is good, this is the real deal, this needs to happen.

Startups are about passion

The "great idea" has you in its gripping hand.  Odds are you have visions of money, fame, or immense positive change bouncing around in your head as a result of The Great Idea getting out to the masses.  It's got you, and when you think about it, you get all excited and fired up.  That guy you discussed it with and who shrugged—who cares about him?  That gal you described it to and who thought it sounded lame—who needs her?  You know it's a cool idea.

And you might even be self-aware enough to realize that your idea might only be exciting to you.  But you can't help thinking that's now ... just wait till they see it!

Startups are about passion for a "great idea"—your idea.  You thought it up, it kicked around in your head and decided to make it your home, and you can't stop thinking about it now and wondering what if.  So you are going to make it happen.

Micro-startup?

Or call it "getting up early and staying up late to work on my idea until I get it out."  Same passion as a startup in Silicon Valley, just done a smaller scale and in a more peaceful place.  We have an investor—me and my family.  We are putting our brains and talent into this idea, and we are excited about where this idea might lead.  More ideas, new opportunities, new courses or paths—who knows what comes of pursuing a great idea with all your excitement and passion?

Whatever does come of it, it's going to be fun :-)

That's what I meant by "in the end, none of that really matters."  Oh sure, I have some spreadsheets about sales, project plans about effort and features, ideas for future versions or other apps.  But in the end, it's about pursuing a passion.  You can obsess about the details all you want, but that "great idea" just won't let go.  What might happen if you pursued it?  What might happen if you succeed?

The passion and curiosity just gets a hold of you.  You have to find out how the story ends.

Let's do this thing!

2011/02/27

Interviewing Tips

At my current gig, we are hiring Perl programmers. Lots of them. I mean, not tens of thousands, but we are actively interviewing people. And as I interview these applicants a few things have jumped out at me. I'll confess I thought all these things were obvious and self-evident. But after half a dozen candidates all making similar mistakes, I figured maybe I'd post about it. Following my tips won't get you a job, but it might prevent you from losing an opportunity you might have been well-suited for.



1. Know Your Target Company
Like I said, I thought this was obvious, but apparently not. If you are applying for a job at a company, a few minutes on Google will tell you quite a bit about that company. Why you would ever apply at a company you don't know anything about is beyond me.

Perhaps you are desperate for a job and so you sent out hundreds of applications? I'm not sure how wise a strategy that is, but you have at least 5 minutes before the first phone call to do some sleuthing. If you are in such dire straits that you are sending out applications willy-nily, surely 5 minutes to do some basic research about the company would be a good idea?

This is especially important since companies like to think you are interested in them. For some reason, we aren't too keen on hiring people who could care less about our goals and interests. Just sayin' ...

2. Tell Me Why You Should Have the Job
Ah, the lost art of the cover letter. It goes hand-in-hand with #1. If you know anything about the company and you have any related job skills, you should have a clear idea of why the company should hire you. Let me give you an example:

You write Perl. You see my job posting for Perl programmers specializing in MVC. You look up my company and see we are into making websites. Ok, here's you chance! Tell me why I should hire you. It should be obvious, right?

  • I've been writing Perl for X years, and I have successfully completed Y number of projects that allows customers to create websites. I wrote several specialized toolkits for easy processing of data and creating HTML pages from it. Blah, blah, blah.
  • I've also been experimenting with iOS/Android/WebOS/WP7 (God help you), and I have some experience in making websites scale to these emerging platforms. While this may not be your current target, I believe my experience here could blah, blah, blah, blah
See what I did there? I took related skills, and I combined them with a cursory knowledge of the company and position. With that very simple combination, I specifically show how you could be useful to the company.

This is apparently a new concept to a lot of people. My mother—the long-suffering English teacher—is shaking her head right now, as she has taught this to High School Juniors for years. It's called a "cover letter". You don't even need the formal cover letter in today's email-centric world. Just give me a blurb about your experience (executive summary tailored for my job posting) and another realistic blurb about how you think your skills would be a good fit. Put it right there in the email where you send me your resume (in PDF, for crying out loud—what's wrong with you?).

Really, it's not that hard. And you would be surprised how much it impacts your interview process.

3. Know Your Stuff (Duh)
If you are interviewing for a Java job, you better know your collection classes. If you are interviewing for your Perl, you better know how to use regexes to capture text. If you are interviewing for JavaScript, you better understand prototype-based inheritance.

Here's a tip: before the phone interview where I (or someone else) calls you and grills you about your technical knowledge, why not brush up on what you are interviewing for? Seriously.

If you are interviewing for a Perl job, I expect you to know regexes. I'm not expecting you to be the Regex God, but I am expecting you to know how to capture text with regexes. You might slip on some syntax here or there, but you need to know the basics.

Kind of obvious, but again, I've been seeing problems :-(

4. Know How To Say "I don't know" Properly
Question: how do the Perl functions exec() and system() differ?

Now if you know the answer, awesome. But eventually, you are going to have that interview where you will not know the answer. The following are two examples of saying "I don't know."

Answer 1: I don't know.
Answer 2: I don't know. But I know that system() does X, Y, Z, so if I were to guess, about exec(), maybe it's about A and B? Can you give me a context in which they might be used?

I'm going to give you exactly one guess which one helps you in an interview.

5. Know How to Be Wrong
Along with knowing how to say "I don't know properly" is the valuable skill of knowing how to be wrong in an interview. Because eventually, you are going to get an answer wrong. It happens to the best of us, and I'll let you in on a secret: most interviewers are purposefully trying to make you screw up.

Now sometimes that's because you are being interviewed by a sadist (it happens). But usually, it's because the interviewer is trying to find out what you know, and they can only do that by asking you a whole range of questions. But more important than what you know is how you handle what you don't know. In software, you are always having to learn new things, always getting tossed into the deep end (sometimes with some bowling balls to juggle). We interviewers know this. So we purposefully try to find holes in your knowledge or trip you up. We want to watch how you think, how you react, how you approach being in over your head.

Sometimes you can get more than half the questions wrong and still pass the interview with flying colors. No joke.

I'm not sure there's one, right way to handle being wrong. But I can tell you some very unhelpful ways to handle it:

Defensive: It's an interview. Breathe. It's ok. We all hate being wrong (trust me, I get it). It's not the end of the world, and no matter how much you want this job, being defensive about being wrong is not going to get you the job. Quite the opposite, actually.

Excuses: There's a fine line between explaining how you got tripped up (sometimes useful) and making excuses. Tip: don't blame the interview question—even if it was a crappy question :-)

Dismissive: "I don't see why you would do that anyways." Oh boy. It's an interview question, my friend. Of course, it may be contrived. It might even be purposefully confusing. That's not the point. The point is that you were asked a question, and the interviewer wants an answer. You may think it's a dumb question, but saying so isn't winning you points. Just sayin' ;-)

6. Be On Your Best Behavior
Unless you are interviewing with some very, very weird company, they are probably looking for an individual with the following traits:
  • Friendly
  • Able to get along with others
  • Not prone to outbursts of anger
  • Willing to give the benefit of the doubt
  • Hard worker
  • "Team player"
Companies are made up of people. People need to (more or less) get along. During the interview is not the time to highlight how you do not suffer fools or idiots. It's not the time to brag about how you had this manager who was an idiot and they dismissed your idea—and how you went around them and triumphed. It's not the time to talk about how much your current job sucks.

I cannot underscore the importance of this one. We'd rather hire a humble, friendly intermediate programmer with a lot to learn than some rock-star programmer who treats everyone else as lesser beings beneath his brilliance. All the better if you are a rock-star and know how to get along with people!

7. Work On Your Resume (Please)
This may be because my mom was an English teacher or because I took English Literature as a major, or just because I like to read. Whatever the reason, I highly recommend you put some work into your resume.

As for me, I found a really good format that worked for me and worked for my interviews. I've been using the same format for years (literally since 1997), and it serves me fine. But I update it every year, and I always check it for typos or awkward wording. Not because I'm looking for a job, but because that resume is such an important part of my career.

Don't just slap your resume together. Don't give me the same resume you gave the other guy—especially if we are not in even remotely related fields or vertical markets. I'm not saying you need to customize your resume for each job; I am saying you need to consider it though.

Say you made your bread-and-butter in Java like I did, and you are now applying for a job at a Mobile App company. Now is the time to go back and change your resume to highlight all the skills or projects that make you an ideal fit for this Mobile company. Don't give me a resume all about your EJB experience when all I care about is your iOS or Cocoa experience. Instead, highlight how your projects were about distributed apps, high volume processing, high reliability, flexible UIs based on clients, etc. I.e. give me something that shows that even your experience from 10 years ago is actually an asset—one I should not go another day without having on my team!

Oh, and give me the resume in PDF, type-set in all its awesome glory. Don't give it to me in DOC or DOCX where it might not display on my version of Word or on my Mac. Why short-change yourself? Just print it to PDF (take a look at PDF Creator if you are not blessed to be running a Mac) and make it as portable and beautiful as possible. Or send me both. But make sure I get the PDF.



There are many more tips, but I thought I'd just get these obvious ones out of the way.

To those out there job hunting, good luck! I mean it. I've been on both sides of the process, and I know how nerve wracking it can be to be out there, searching and searching for a job. Just take the time to work on these simple points and your interviews will be a lot more productive!