06 December 2012

Dave Brubeck, RIP

05 December 2012

Monster Devours Passwords!

I'm extremely impressed with the news that I read today: New 25 GPU Monster Devours Passwords In Seconds.

Wow.  This really is a monster machine, which pulls together quite a few interesting pieces of technology.  Very impressive work!

The things that I take away from this are as follows:

  1. In any new system that I design, I will definitely use a password hashing algorithm that is stronger than bcrypt with five rounds.  I'm still pretty enamored with bcrypt for obvious reasons.
  2. Technologies that get us beyond straightforward password schemes are going to be more and more important in the future:  two-factor authentication, etc.
  3. Passwords have the stink of death about them.

Very impressive work epixoip!

28 November 2012

12 November 2012

Advanced, Server-Side Mail Filtering For Increasing Productivity and Maintaining Sanity


A company that I work with uses Salesforce.com for various CRM functions.  I receive a regular stream of emails from Salesforce.com with Subject: headers that look something like this:

New case comment notification. Case Number 00012345
New case comment notification. Case Number 00533654
New case comment notification. Case Number 00667788
New case comment notification. Case Number 00887644

There are various other Subject headers as well.  These emails get generated anytime a customer or a colleague does anything associated with a Salesforce case.  Like I said, I receive a regular stream of messages like this one.

I find these emails to be really inconvenient.  While it is true that all of these emails include a URL back to Salesforce.com so I can refer to the Salesforce case, the problem is that I am a serious email user and I rely upon email Subject: headers to be able to sort and prioritize my email.  Quite frankly, when I look at an email Inbox with Subjects: like above, I can't quickly figure out which messages require immediate attention and which other ones are lower-priority.

These emails would be a lot easier to deal with if they had Subject: headers like this:
 
SF 00012345 - Acme Inc. - foo.jsp doesn't display under Chrome
SF 00533654 - FrozzBozz Inc. - problem exists between keyboard and chair
SF 00667788 - University of Nowhere - performance problem
SF 00887644 - Acme Inc. - I18N problem

I've been told through various channels that for these emails to be improved on the Salesforce side of the connection is 'impossible'.  I don't know if the problem here is technical or political, but I have heard about other Salesforce customers who complain about the same problem.

Quite frankly, I can't get my work done every day if I am going to be interrupted by a regular stream of email messages with confusing Subjects of 'New case comment notification.  Case Number 00887644'. So, I decided I needed to create a utility to fix this problem.

One caveat that I should mention in all of this is that I don't really deal with Salesforce's CRM via email except from the mail that I receive from Salesforce.  I never send mail to Salesforce -- the way that this utility changes Subject headers is something that is convenient for me but it might interfere with how other systems are configured to deal with Salesforce.

...........

Another problem that I have in this area is that at my work-site I access my email via the company's IMAP server.  I do run my own IMAP server at home for my own email, but at work I really do not want ot be running my own IMAP server.  There is no way that I can run any kind of non-trivial mail-processing code on the company's IMAP server.


So, anyways, I wrote a utility to solve the problems I was having in this area:

https://gitlab.com/kdc1024/salesforce-hacks


I'm very happy to say that my productivity has gone up quite a bit at work since I've started using this utility.  Also, my stress level has decreased by quite a bit.  It is very cool to be able to filter my mail (using a very non-trivial filter) on the server-side.

31 October 2012

Violent Agreement with "You should let it crash"

I nod my head in violent agreement with Erik Kronberg's You should let it crash.

Gheesh.  Frequently, I feel like I am in the minority with this opinion.

Take, for example, this third-party vendor Java code that I was perusing once:


    try {
        ....
        for(int i=0; i < someVector.size(); i++) {
            obj = someVector.get(i);
            obj.doSomething();
        }
    }
    catch(Exception e){ }
 
This is (pretty close to...) REAL CODE from a REAL PRODUCT that I worked with once.

Do you want to know what the problem with this code was?

Here's the problem:  See that "catch(Exception e) {}" block?  Well, it turns out that this block was semi-frequently catching an java.lang.ArrayIndexOutOfBoundsException.

I'm going to let you think about this for a moment....

The problem with the code in the product that I was working with was that this "catch" block was obscuring a very real problem in the code.

When I look at code like this, here is how I interpret the original programmer's intentions as he/she wrote the code:

There seems to be a problem here in this code.  However, I'm too lazy to actually figure out what is going wrong here.  Instead of fixing the actual problem that is wrong here, I am going to sweep the problem under the rug.  This might cause some cascade of strange problems in the future execution of this program, and fixing these new problems might take 100 times longer to fix because of this shoddy coding practice that I am employing here, but I am OK with this.

I am a big believer in "always keep your program's execution in a known state".  If the program's execution is not in a known state, then it would be best if this problem were fixed sooner rather than later.  Fixing the problem "sooner" might involve letting your program crash, logging the error, and then restarting.  But, sweeping problems under the rug is simply not acceptable.


12 September 2012

Semaphores

In the style of The Profound Programmer, I present the following:



[text:  "Perhaps you should have somebody on your development team that understands how to use semaphores and other synchronization primitives", photograph reminds people that in some systems, a system failure is a lot more inconvenient than simply having to restart]


Image credit:   http://www.flickr.com/photos/smithsonian/4011428942/


If you buy me beer I might even tell you how I got the inspiration for this creation.  Let's just say that my inspiration came from code I looked at a long time ago.

14 August 2012

The difference between being 'frugal' and 'cheap'

During my commute this morning the following story made my head spin:

http://www.npr.org/2012/08/14/158741797/boosting-travel-options-google-to-buy-frommers

....
NPR's business news starts with a travel deal for Google.

(SOUNDBITE OF MUSIC)

GREENE: Google is buying the Frommer's travel guide business from a New York publisher. The search giant is trying to offer more robust travel-related results and, of course, sell more ads.
Here's NPR's Wendy Kaufman.
WENDY KAUFMAN, BYLINE: When Seth Kugel, who writes the Frugal Traveler column for The New York Times, first heard about the deal, he thought...
SETH KUGEL: Great. I mean, if Frommer's content ends up on line for free, that will save cheapskates like me a lot of time sitting on the floor of the local Barnes and Noble and scrolling down notes from guidebooks there.
KAUFMAN: Frommer's is a huge name in travel. It's been producing authoritative guidebooks for well over half a century. They're based on rigorous research and are written by pros.
That's quite different from what's found on sites like TripAdvisor or Travelocity. Last year, Google bought Zagat another well-respected travel and leisure publication.
Google isn't saying exactly what its plans are for Frommer's - but some observers are wary of the company's increasing market power in online travel. They fear search results could unfairly favor Frommer's or Zagat's content over material from other sites.
And writer Seth Kugel has another concern.
KUGEL: I definitely know some quality writers that write for Frommer's and I'm certainly worried that they will no longer have the same resources to use to travel and do real travel writing and real criticism.
.....

Wait!  Let me see if I understand this correctly.  Mr. Kugel thinks that we should all hear his opinion on this Google/Frommer deal.  He has some concerns about the deal itself.  He''s concerned that the working folks at Frommers might not have enough resources to do a high-quality job.  But.....he already admitted (above) that he doesn't even pay for their work.  He sits in a brick-and-mortar bookstore and reads their books for free, defrauding both the folks who work at the store itself as well as the staff of Frommers.

Did I miss anything?


10 August 2012

The Profound Programmer

The Profound Programmer is an awesome site, and I think I will probably have to order from them soon.

Here are...some....of my favorites:


 







If I were to ever meet the folks who put this together, I would buy them beer and we could exchange many colorful stories.

06 August 2012

Evans Notch / Crawford Notch / Bear Notch Ride

It was a nice ride. I guess you could say that this ride had a little bit of everything. Or, maybe you could say that it had a lot of everything...


Bike route 1744872 - powered by Bikemap 

31 July 2012

The Pig Ride!



Bike route 1291769 - powered by Bikemap

Oink! Oink! The Pig Ride never disappoints.

11 June 2012

Needs more salt, but more importantly, needs more rounds

Like many people, I use LinkedIn to maintain connections in my professional world. So, when the recent news of the security breach at LinkedIn came out, I poked around a little bit.   Interestingly enough, my long, random password's hash does not appear in the leaked password hash file.  Despite this fact, I changed my password just to be safe.

As far as LinkedIn goes, I am somewhat disappointed.

I've seen lots of comments in the news lately regarding the fact that the password hashes were unsalted. The thing is, I don't think that this was the biggest problem here.  Sure, salt is important, but....

In a recent project that I have been working on, I've been playing around with "Eksblowfish" (link and link).  The more I've played around with Eksblowfish over the past few months, the more enamored I've become with it. Here is a password hashing scheme that really gets things right -- it is a hashing algorithm that...over time...can be configured to keep in step with rapid increases in CPU power.

I'm not the only person who thinks this way either.  Check this out.

I use certain hashing algorithms in some of the protocol work that I sometimes work on.  When I'm working on protocol stuff, the hashing algorithms that I select for my work are algorithms that are more designed for speed.  The protocols that I design always always always have to be fast, efficient and secure.

However, a hashing algorithm designed for speed is not really a good choice for a password hashing algorithm.  In the case of a password hashing algorithm, the criteria is less on speed but instead more on defending against some jerk who happens to have stolen your user's hashes.  Situations like this might be inevitable ; I don't know.  However, what I do know is that if/when this happens, you might as well make it really really difficult for the jerks to mount a dictionary attack against your site's stolen password hashes.

The staff at LinkedIn should definitely consider putting in place a scheme that migrates newer password changes on their site to Eksblowfish hashes...and...while they're at it, they should make sure that they're specifying a number of "rounds" that ensures that future attackers will have a really hard time if they manage to (again) steal the password hashes.

28 May 2012

Nubble Ride 2012

Nice ride up to the Nubble on Saturday. I'm glad we went early, because it got hot!



Bike route 1597220 - powered by Bikemap
 

24 May 2012

Too many functions

I nearly fell out of my chair laughing after reading this article on The Daily WTF:

"It's just too slow," James replied, "once I have real data in there, it takes almost five seconds to add, remove, or find, an item."
Yakir knew something was definitely wrong and sat with James to look at his code. Here's what he saw...

.......

"Uhhh," Yakir said, baffled. "Why didn't you use the built-in Hashtable class from System.Collections that I showed you?" 
"I checked it out," James explained, "but it had too many functions, which means it's slow. My class only has 3 functions, so it's much more efficient."



I think I've worked with James' cousin!!!

10 May 2012

MLB Security Fail






LOL, indeed!

Got this from Bruce


27 April 2012

Life Imitates An XKCD Cartoon, Hilarity Ensues

Seen on StackOverflow:

How can I pass the string “Null” through wsdl (SOAP) from AS3 to ColdFusion web service without receiving a “missing parameter error”?
We have an employee whose last name is Null. He kills our employee lookup app when his last name is used as the search term (which happens to be quite often now).


Clearly, this employee comes from a long lineage of people who were destined to break poorly glued together computer systems.

18 April 2012

I Love Lucy Almost As Much As I Love Successful Optimization Efforts

I've had a good couple of days.

This started a couple of days ago, when I became aware of a rather serious performance problem in some code that I help maintain.  This problem exhibited itself on a busy production machine with lots of users.  Solving this problem was Very Important.

At this point I started gathering data, trying to answer the question "where in the code are things going bad?".

After many hours of data collection, I analyzed the data and got a sense of the general neighborhood of the problem.  I looked at the code in this area and thought about what was really going on in this area of the code.  Eventually, I had a mini-epiphany:  I realized that the algorithm I was looking at was (in a non-obvious way) actually an O(N) algorithm, and that I could probably replace it with an O(1) algorithm.

So, I rolled up my sleeves and implemented that O(1) algorithm I had in mind.  After doing all of the testing that I could think of, I installed the new code on the production machine.

Like I said, this code was running on a production machine with lots of users.  It didn't take long for the traffic load to ramp up.  I'm pretty happy with the results:  before my new code was installed on the production machine, this four-CPU-core machine had a 15-minute load-average of around 12.0 .  After my updated code was deployed on the machine, the 15-minute load-average dropped down to 3.0.

Fifteen-minute load-averages of ~12.0 on a four-core machine remind me of a certain scene from "I Love Lucy".  I'm glad I was able to help solve this problem without having to acquire some new hardware....



09 April 2012

How Not To Iterate

I can't believe that I am currently devoting serious brainpower into rewriting some code that I got from ${third_party_vendor}.  The code sort-of looks like this:


import java.util.*;

// This class defines an object that, for whatever reason,
// can expired over time.  When this object has expired, 
// it can be removed from the system.
class SomeObjectThatCanExpire 
{
    private boolean expired = false;

    public boolean getExpired() { return expired; }
    public void setExpired(boolean e) { expired = e; }
}

.....

class StupidArrayIterationTest
{
    public static void main(String argv[])
    {
        int i;
        ArrayList al = new ArrayList();

        for (i=0; i<10; i++) {
            al.add(new SomeObjectThatCanExpire());
        }

        ....time passes....

        // remove all expired objects from the system
        // (unfortunately, this code is incorrect)
        for (i=0; i < al.size() ; i++) {
            if (al.get(i).getExpired() == true) {
                al.remove(i);
            }
        }
    }
}

The hilarious thing about the code that I am dealing with is that everything is a bit more complicated than this toy code, and that the original programmer(s) seemed to be dimly aware of the problem here ("gee, why don't all of the expired objects get removed from the "list"?).  But...instead of fixing the problem correctly, they built some crazy scheme in this area of the code to address the problem.

Of course, the "scheme" that was developed in this case is also buggy.  So, my task is to rip out all of this insane code and try to ensure that no crazy side-effects are triggered when the code in this area is actually run correctly.

Who writes code like this?    Arrrrgggghhhhh......

01 April 2012

Perhaps certain social networks should give a complimentary "I like to be stalked!" t-shirt to their members?



Ewwww.... This is creepy.

However, it is also unsurprising.   It is easy for anybody with decent reasoning skills to be able to see that this is just the logical consequence of what happens when people share so much of their information with social networks whose entire purpose is to learn more about you....and then to make this information available to other entities...

I think that this is one of the best points made in the article:
This is an app you should download to teach the people you care about that privacy issues are real, that social networks like Facebook and Foursquare expose you and the ones you love, and that if you do not know exactly how much you are sharing, you are as easily preyed upon as if you were naked.
As someone who cares deeply about security and privacy issues, I hope that this app serves as an effective wake up call.

15 March 2012

Good writing, bad writing

Last night, as I was perusing the news, I read two sentences from two different articles published in two different newspapers.

In the New York Times article "The Fight Club Generation", we read this:

It’s like a boxing match crossbred with WrestleMania, presented in the middle of an Insane Clown Posse concert.

Meanwhile, in the Fosters Daily Democrat, the first sentence in the article "UNH lecturer elected to Durham Town Council" is this:

An English lecturer from the University of New Hampshire is now on the Town Council, along with keeping the university's architect to serve as a public library trustee.

I thought that one of these articles was well-written, and the other made my head hurt.  I'll leave it up to you to guess which article I liked and which one I did not.

06 March 2012

What I Actually Do...



Of course, you can tell it's not me in the picture because this gentleman has his mouse on the wrong side of the keyboard....

30 January 2012

Tabs versus spaces



(Source for this image)

I'm in the "spaces" camp myself.  I used to work in a shop with a bunch of Windows programmers who used tabs (that's what their IDE did).   In an effort to try to fit in, I configured my .emacs file to use tabs.  Still, my preferences are for spaces.

Of course, the most cogent article I've read on this topic comes from jwz.

12 January 2012

She Moves In Mysterious Ways



So, there I was, driving to work this morning.  It was snowing, and the roads were sketchy.

I was drving at a reasonable 45mph.  Traffic on the roads was pretty light.

In my rear-view mirror I saw a pair of headlights appear.  Whoever was driving the car was traveling faster than I was -- it didn't take long for this car to catch up with me.

At the point that this car caught up with me, I had just entered a passing zone.  The new car immediately moved to the left to pass me.

I watched all of this with more than passing curiosity (ha ha ha...).  Now that this car was out in the passing lane, it was driving on the lightly-traveled lane.  Unlike the lane that I was traveling in, the passing lane was pure snow and not bare-ish pavement.  I was trying to ensure that if this car spun out, that it didn't also take me out.

The driver of the other car was really fighting to pass me.  I could see and hear the car slipping and sliding as it passed me at around 50mph.

As the car got up along side my own car, I glanced over at the car, wondering to myself "who in the hell is driving this thing?" and "are they crazy?".

So, I looked over at this car.  Subaru Sedan (OK...).  The driver?  A nun.  Full habit -- the whole bit.  She was really focused on her driving -- two hands on the wheel, at the ten and two-o-clock positions, and she was leaning forward in her seat, face near the steering wheel, peering off into the snowstorm.  She never glanced over at me.  The nun finally managed to pass me, and then she jumped back into the well-traveled lane and sped up again.  I assume that this whole incident scared her a little bit, because she didn't use the passing lane after this, despite ample opportunity to do so.  I was still two cars behind her a couple of miles later.

I would bet $100 that somewhere in her car she had a Saint Christopher statue.