Re-typing Parent Class Attributes in TypeScript

I was recently working on converting some code away from Backbone.js and toward Spina, our TypeScript Backbone “successor” used in Review Board, and needed to override a type from a parent class.

(I’ll talk about why we still choose to use Backbone-based code another time.)

We basically had this situation:

class BaseClass {
    summary: string | (() => string) = 'BaseClass thing doer';
    description: string | (() => string);
}

class MySubclass extends BaseClass {
    get summary(): string {
        return 'MySubclass thing doer';
    }

    // We'll just make this a standard function, for demo purposes.
    description(): string {
        return 'MySubclass does a thing!';
    }
}

TypeScript doesn’t like that so much:

Class 'BaseClass' defines instance member property 'summary', but extended class 'MySubclass' defines it as an accessor.

Class 'BaseClass' defines instance member property 'description', but extended class 'MySubclass' defines it as instance member function.

Clearly it doesn’t want me to override these members, even though one of the allowed values is a callable returning a string! Which is what we wrote, darnit!!

So what’s going on here?

How ES6 class members work

If you’re coming from another language, you might expect members defined on the class to be class members. For example, you might think you could access BaseClass.summary directly, but you’d be wrong, because these are instance members.

Peer-Programming a Buggy World with ChatGPT AI

AI has been all the rage lately, with solutions like Stable Diffusion for image generation, GPT-3 for text generation, and CoPilot for code development becoming publicly available to the masses.

That excitement ramped up this week with the release of ChatGPT, an extremely impressive chat-based AI system leveraging the best GPT has to offer.

I decided last night to take ChatGPT for a spin, to test its code-generation capabilities. And I was astonished by the experience.

Together, we built a simulation of bugs foraging for food in a 100×100 grid world, tracking essentials like hunger and life, reproducing, and dealing with hardships involving seasonal changes, natural disasters, and predators. All graphically represented.

We’re going to explore this in detail, but I want to start off by showing you what we built:

Also, you can find out more on my GitHub repository

A Recap of my Experience

Before we dive into the collaborative sessions that resulted in a working simulation, let me share a few thoughts and tidbits about my experience:

The End of COVID.. Data.

This year’s seen a rapid reduction of available COVID data. Certainly in California, where we’ve been spoiled with extensive information on the spread of this virus.

In 2020, as the pandemic began to ramp up, the state and counties began to launch dashboards and datasets, quickly making knowledge available for anyone who wanted to work with it. State dashboards tracked state-wide and some county-wide metrics, while local dashboards focused on hyper-local information and trends.

Not just county dashboards, but schools, hospitals, and newspapers began to share information. Individuals, like myself, got involved and began to consolidate data, compute new data, and make that available to anyone who wanted it.

California was open with most of their data, providing CSV files, spreadsheets, and Tableau dashboards on the California Open Data portal. We lacked open access to the state’s CalREDIE system, but we still had a lot to work with.

It was a treasure trove that let us see how the pandemic was evolving and helped inform decisions.

But things have changed.

The Beginning of the End

The last 6 months or so, this data has begun to dry up. Counties have shut down or limited dashboards. The state’s moved to once-a-week case information. Vaccine stats have stopped being updated with new boosters.

This was inevitable. Much of this requires coordination between humans, real solid effort. Funding is drying up for COVID-related data work. People are burnt out and moving on from their jobs. New diseases and flu seasons have taken precedence.

But this leaves us in a bad position.

Scratching Out AI Chicken Art with Stable Diffusion

I’ve been enjoying playing with Stable Diffusion, an AI image generator that came out this past week. It runs phenomenally on my M1 Max Macbook Pro with 64GB of RAM, taking only about 30 seconds to produce an image at standard settings.

AI image generation has been a controversial, but exciting, topic in the news as of late. I’ve been following it with interest, but thought I was still years off from being able to actually play with it on my own hardware. That all changed this week.

I’m on day two now with Stable Diffusion, having successfully installed the M1 support via a fork. And my topic to get my feet wet has been…

Chickens.

Why not.

So let’s begin our tour. I’ll provide prompts and pictures, but please not I do not have the seeds (due to a bug with seed stability in the M1 fork).

Integration and Simulation Tests in Python

One of my (many) tasks lately has been to rework unit and integration tests for Review Bot, our automated code review add-on for Review Board.

The challenge was providing a test suite that could test against real-world tools, but not require them. An ever-increasing list of compatible tools has threatened to become an ever-increasing burden on contributors. We wanted to solve that.

So here’s how we’re doing it.

First off, unit test tooling

First off, this is all Python code, which you can find on the Review Bot repository on GitHub.

We make heavy use of kgb, a package we’ve written to add function spies to Python unit tests. This goes far beyond Mock, allowing nearly any function to be spied on without having to be replaced. This module is a key component to our solution, given our codebase and our needs, but it’s an implementation detail — it isn’t a requirement for the overall approach.

Still, if you’re writing complex Python test suites, check out kgb.

Deciding on the test strategy

Review Bot can talk to many command line tools, which are used to perform checks and audits on code. Some are harder than others to install, or at least annoying to install.

We decided there’s two types of tests we need:

1. Integration tests — ran against real command line tools
2. Simulation tests — ran against simulated output/results that would normally come from a command line tool
   

Being that our goal is to ease contribution, we have to keep in mind that we can’t err too far on that side at the expense of a reliable test suite.

We decided to make these the same tests.

The strategy, therefore, would be this:

1. Each test would contain common logic for integration and simulation tests. A test would set up state, perform the tool run, and then check results.
2. Integration tests would build upon this by checking dependencies and applying configuration before the test run.
3. Simulation tests would be passed fake output or setup data needed to simulate that tool.
   

This would be done without any code duplication between integration or simulation tests. There would be only one test function per expectation (e.g., a successful result or the handling of an error). We don’t want to worry about tests getting out of sync.

Regression in our code? Both types of tests should catch it.

Regression or change in behavior in an integrated tool? Any fixes we apply would update or build upon the simulation.

Regression in the simulation? Something went wrong, and we caught it early without having to run the integration test.

Making this all happen

We introduced three core testing components:

1. @integration_test() — a decorator that defines and provides dependencies and input for an integration test
2. @simulation_test() — a decorator that defines and provides output and results for a simulation test
3. ToolTestCaseMetaClass — a metaclass that ties it all together
   

Any test class that needs to run integration and simulation tests will use ToolTestCaseMetaClass and then apply either or both @integration_test/@simulation_test decorators to the necessary test functions.

When a decorator is applied, the test function is opted into that type of test. Data can be passed into the decorator, which is then passed into the parent test class’s setup_integration_test() or setup_simulation_test().

These can do whatever they need to set up that particular type of test. For example:

• Integration test setup defaults to checking dependencies, skipping a test if not met.
• Simulation test setup may write some files or spy on a subprocess.Popen() call to fake output.

For example:

class MyTests(kgb.SpyAgency, TestCase,
              metaclass=ToolTestCaseMetaClass):
    def setup_simulation_test(self, output):
        self.spy_on(execute, op=kgb.SpyOpReturn(output))

    def setup_integration_test(self, exe_deps):
        if not are_deps_found(exe_deps):
            raise SkipTest('Missing one or more dependencies')

    @integration_test(exe_deps=['mytool'])
    @simulation_test(output=(
        b'MyTool 1.2.3\n'
        b'Scanning code...\n'
        b'0 errors, 0 warnings, 1 file(s) checked\n'
    ))
    def test_execute(self):
        """Testing MyTool.execute"""
        ...

When applied, ToolTestCaseMetaClass will loop through each of the test_*() functions with these decorators applied and split them up:

• Test functions with @integration_test will be split out into a test_integration_<name>() function, with a [integration test] suffix appended to the docstring.
• Test functions with @simulation_test will be split out into test_simulation_<name>(), with a [simulation test] suffix appended.
  

The above code ends up being equivalent to:

class MyTests(kgb.SpyAgency, TestCase):
    def setup_simulation_test(self, output):
        self.spy_on(execute, op=kgb.SpyOpReturn(output))

    def setup_integration_test(self, exe_deps):
        if not are_deps_found(exe_deps):
            raise SkipTest('Missing one or more dependencies')

    def test_integration_execute(self):
        """Testing MyTool.execute [integration test]"""
        self.setup_integration_test(exe_deps=['mytool'])
        self._test_common_execute()

    def test_simulation_execute(self):
        """Testing MyTool.execute [simulation test]"""
        self.setup_simulation_test(output=(
            b'MyTool 1.2.3\n'
            b'Scanning code...\n'
            b'0 errors, 0 warnings, 1 file(s) checked\n'
        ))
        self._test_common_execute()

    def _test_common_execute(self):
        ...

Pretty similar, but less to maintain in the end, especially as tests pile up.

And when we run it, we get something like:

Testing MyTool.execute [integration test] ... ok
Testing MyTool.execute [simulation test] ... ok

...

Or, you know, with a horrible, messy error.

Iterating on tests

It’s become really easy to maintain and run these tests.

We can now start by writing the integration test, modify the code to log any data that might be produced by the command line tool, and then fake-fail the test to see that output.

class MyTests(kgb.SpyAgency, TestCase,
              metaclass=ToolTestCaseMetaClass):
    ...

    @integration_test(exe_deps=['mytool'])
    def test_process_results(self):
        """Testing MyTool.process_results"""
        self.setup_files({
            'filename': 'test.c',
            'content': b'int main() {return "test";}\n',
        })

        tool = MyTool()
        payload = tool.run(files=['test.c'])

        # XXX
        print(repr(payload))

        results = MyTool().process_results(payload)

        self.assertEqual(results, {
            ...
        })

        # XXX Fake-fail the test
        assert False

I can run that and get the results I’ve printed:

======================================================================
ERROR: Testing MyTool.process_results [integration test]
----------------------------------------------------------------------
Traceback (most recent call last):
    ...
-------------------- >> begin captured stdout << ---------------------
{"errors": [{"code": 123, "column": 13, "filename": "test.c", "line': 1, "message": "Expected return type: int"}]}

Now that I have that, and I know it’s all working right, I can feed that output into the simulation test and clean things up:

class MyTests(kgb.SpyAgency, TestCase,
              metaclass=ToolTestCaseMetaClass):
    ...

    @integration_test(exe_deps=['mytool'])
    @simulation_test(output=json.dumps(
        'errors': [
            {
                'filename': 'test.c',
                'code': 123,
                'line': 1,
                'column': 13,
                'message': 'Expected return type: int',
            },
        ]
    ).encode('utf-8'))
    def test_process_results(self):
        """Testing MyTool.process_results"""
        self.setup_files({
            'filename': 'test.c',
            'content': b'int main() {return "test";}\n',
        })

        tool = MyTool()
        payload = tool.run(files=['test.c'])
        results = MyTool().process_results(payload)

        self.assertEqual(results, {
            ...
        })

Once it’s running correctly in both tests, our job is done.

From then on, anyone working on this code can just simply run the test suite and make sure their change hasn’t broken any simulation tests. If it has, and it wasn’t intentional, they’ll have a great starting point in diagnosing their issue, without having to install anything.

Anything that passes simulation tests can be considered a valid contribution. We can then test against the real tools ourselves before landing a change.

Development is made simpler, and there’s no worry about regressions.

Going forward

We’re planning to apply this same approach to both Review Board and RBTools. Both currently require contributors to install a handful of command line tools or optional Python modules to make sure they haven’t broken anything, and that’s a bottleneck.

In the future, we’re looking at making use of python-nose‘s attrib plugin, tagging integration and simulation tests and making it trivially easy to run just the suites you want.

We’re also considering pulling out the metaclass and decorators into a small, reusable Python packaging, making it easy for others to make use of this pattern.

What If: Ditching Social Security Numbers for Personal ID Keys

I’ve been thinking about this discussion on a National ID and the end of using Social Security Numbers. We’re used to having these 9 digit numbers represent us for loans, credit card transactions, etc., but in the modern age one would think we could do better.

Any replacement for Social Security Numbers would need to be secure, reduce the chances of identity theft, be able to withstand fraud/theft, and must not be scannable without knowledge (to avoid being able to track a person without their knowledge as they go from place to place). The ACLU has a list of 5 problems with National ID cards, which I largely agree with (though some — namely the database of all Americans — already exist in some forms (SSN, DMV, Facebook) and are probably inevitable).

In an ideal world, we’d have a solution in place that offered a degree of security, and there are technical ways we could accomplish this. The problem with technical solutions is that not every person would necessarily benefit (there are still plenty of Americans without easy access to computers), and technical solutions leading to complexity for many. However, generations are getting more technically comfortable (maybe not literate, but at least accustomed to being around smartphones and gadgets), and it should be possible to design solutions that require zero technical expertise, so let’s imagine what could be for a moment.

Personal ID Keys

Every year we have to renew our registration on our cars, and every so many years we have to renew our drivers license cards. So we’re used to that sort of a thing. What if we had just one more thing to renew, a Personal ID Key that went on our physical keychain, next to the car keys. Not an ID number to remember or a card that can be read by any passing security guard or police officer or device with a RFID scanner, but a single physical key with a safe, private crypto key inside, a USB port on the outside, that’s always with us.

I’m thinking something like a Yubikey, a simple physical key without any identifiable information on the outside that can always be carried with you. It would have one USB port on the outside and a single button (more on this in a minute). You’d receive one along with a PIN. People already have to remember PINs for bank accounts and mobile phones, so it’s a familiar concept.

Under the hood, this might be based around PGP or a similar private/public key cryptography system, but for the purpose of this “What if,” we’re going to leave that as an implementation detail and focus on the user experience. (Though an advantage of using PGP is that a central government database of all keys is not needed for all this to work.)

When you receive your Personal ID Key and your PIN (which could be changed through your computer, DMV, or some other place), it’s all set up for you, ready to be used. So how is it used? What benefits does this really give? Well, there’s a few I can think of.

Signing Documents

When applying for a home loan or credit card agreement, or when otherwise digitally signing a contract online, you’d use your Personal ID Key. Simply place it in the USB port and press the activation button on the key. You’ll have a short period of time to type your PIN on the screen. That’s it, you’re done. A digital signature is attached to the document, identifying you, the date, and the time. That can be verified later, and can’t be impersonated by anyone else, whether by a malicious employee in the company or a hacker half-way across the world.

Replacing Passwords

People are terrible when it comes to passwords. They’ll use their birthdates or their pet’s name on their computer and every site on the Internet. More technical people try to solve this with password management products, but good luck getting the average person to do this. I’ve tried.

This can be largely addressed with a Personal ID Key and the necessary browser infrastructure. Imagine logging into your GMail account by typing your username, placing your key in the USB port on any computer, pressing the activation button, and typing your PIN. No simple passwords that can be cracked, and no complex passwords that you’d have to write down somewhere. No passwords!

Actually, for some sites, this is possible today with Yubikeys (to some degree). Modern browsers and sites supporting a standard called U2F (such as any service by Google) allow the usage of keys like this to help authenticate you securely into accounts. It’s wonderful, and it should be everywhere. Granted, in these cases they’re used as a form of two-factor authentication, instead of as a replacement for a password. However, server administrators using Yubikeys can set things up to log into remote servers using nothing but the key and a PIN, and this is the model I’d envision for websites of the future. It’s safe, it’s secure, it’s easy.

Replacing the Key If Things Go Wrong

Inevitably, someone’s going to lose their key, and that’s bad. You don’t want someone else to have access to it, especially if they can guess your PIN. So there needs to be a process for replacing your key at a place like the DMV. This is just one idea of how this would work:

Immediately upon discovering your key is gone, you can go online or call a toll-free number to indicate your key is lost. This would lead to an appointment at the DMV (or some other place) to get a new key, but in the meantime your old key would be flagged as lost, which would prevent documents from being signed and prevent logging into systems.

Marking your key as lost would give you a special, lengthy, time-limited PIN that could be used to re-activate your key (in case you found out you left it in your other pants).

The owner of the key would need to arrive at the DMV (or wherever) and prove they are who they say they are and fill out a form for a new key. This would result in a new private key, and would require going through a recovery process for any online accounts. It’s important here that another person cannot pretend to be someone else and claim a new key.

Once officially requested at the DMV, the old key would be revoked and could no longer be used for anything.

Replacing the Key If Standards Change

Technology changes, and a Personal ID Key inevitably will be out-of-date. We’ve gone through this with credit cards, though. Every so often, the credit card company will send out a new card with new information, and sites would have to be updated. Personal ID Keys wouldn’t have to be much different. Get a new one in the mail, and go through converting your accounts. Sites would need to know about the new key, so there’d need to be a key replacement process, but that’s doable.

Back to Reality

This all could work, but in reality we have infrastructure problems. I don’t mean standards support in browsers or websites. That’s all fixable. I mean the processes by which people actually apply for loans, open bank accounts, etc. These are all still very heavily paper-based, and there’s not always going to be a USB port to plug into.

Standards on tablets and phones (in terms of port connectors and capabilities) would have to be worked out. iPads and iPhones currently use Lightning, whereas most phones use a form of USB. Who knows, in a year even Apple’s devices might be on USB 3, but then we’re still dealing with different types of USB ports across the market, with no idea what a future USB 4 or 5 would look like. So this complicates matters.

Some of this will surely evolve. Just as Square made it easy for anyone to start accepting credit card payments, someone will build a device that makes it trivial to accept and verify signatures, portably. If the country moved to a Personal ID Key, and there was demand for supporting, devices would adapt. Software and services would adapt.

So I think we could get there, and I think such a key could actually solve a lot of problems, particularly compared to Social Security Numbers and a National ID Card. Whether people would accept it, and how difficult it would be to get everyone on-board with it, I have no idea, but if designed just right, we could take some major steps toward personal digital security and fraud protection in this country.

Terror with Glaze

The 2016 US Presidential Election has seen its share of controversies and hot-button topics, from the leaked Clinton e-mails to Donald Trump’s statements on Muslims. All have weighed in on the horrible attacks on Paris and Brussels, the threat of ISIS, and even Apple’s fight with the FBI over an encrypted iPhone.

As someone in the technology space, the encryption fight has been simultaneously interesting and concerning to me, as any precedent set could cause serious problems for the privacy and security of all those on the Internet.

The concern by the authorities is that technology-based encryption (which can be impossible to intercept and crack) makes it extraordinarily difficult to stop the next impending attack. Banning encryption, on the other hand, would mean making the average phone and Internet communication less secure, opening the door to other types of threats.

This is an important topic, but what few in the media talk about is that terrorists have been using an alternative method for years before encryption was available to the masses. They don’t talk about it because it hits maybe too close to home.

They don’t talk about the dangers of your local donut shop.

Passing coded messages

Passing a message between conspirators is nothing new. Just as little Tommy might write a coded note in class to Sally so the teacher couldn’t find out, terrorists, crime syndicates, and spy agencies have been using all manner of coded messages for thousands of years to keep their communication secure. Such messages could be passed right in front of others’ noses, and none would be the wiser.

These have been used all throughout history. The German Enigma Code is perhaps one of the most famous examples.

Such messages often entail combinations of letters, numbers, symbols, or may contain specialized words (“The monkey flaps in the twilight,” for instance) that appear as gibberish to most, but have very specific meaning to others. The more combinations of letters, numbers, symbols, or words, the more information you can communicate, and the less likely it is that someone will crack it.

That said, many of these have been cracked or intercepted over time, causing such organizations to become even more creative with how they communicate.

The Donut Code

Donuts have a long history, and its origins are in dispute, but it’s clear that donut shops have been operating for quite some time now. They’re a staple in American culture, and you don’t have to drive too far to find one. Donuts also come in all shapes, sizes, and with all sorts of glazes and toppings, and it’s considered normal to order a dozen or so at once.

In other words, it’s a perfect delivery tool for discrete communication.

When one walks into a donut shop, they’re presented with rows upon rows of dozens of styles of donuts, from the Maple Bar to the Chocolate Old Fashioned to the infamous Rainbow Sprinkle.

While most will simply order their donuts and go, those with something to hide can use these as a tool, a message delivery vehicle, simply by ordering just the right donuts in the right order to communicate information.

Let’s try an example

“I’ll have a dozen donuts: 2 maple bars, 1 chocolate bar, 2 rainbow sprinkles, 3 chocolate old fashioned, 1 glazed jelly, and 2 apple fritters. How many do I have? … Okay, 1 more maple bar.”

If top code breakers were sitting in the room, they may mistake that for a typical donut order. Exactly as intended. How could you even tell?

Well, that depends on the group and the code, but here’s a hypothetical example.

The first and last items may represent the message type and a confirmation of the coded message. By starting with “I’ll have a dozen donuts: 2 maple bars,” the message may communicate “I have a message to communicate about <thing>”. Both the initial donut type and number may be used to set up the formulation for the rest of the message.

Finishing with “How many do I have? … Okay, 1 more maple bar.” may be a confirmation that, yes, this is an encoded message, and the type of message was correct, and that the information is considered sent and delivered.

So the above may easily translate to:

I have a message to communicate about the birthday party on Tuesday.

We will order a bounce house and 2 clowns. It will take place at 3PM. There will be cake. Please bring two presents each.

To confirm, this is Tuesday.

Except way more nefarious.

Sooo many combinations

The other donut types, the numbers, and the ordering of donuts may all present specific information for the receiver, communicating people, schedules, events, merchandise, finances, or anything else. Simply change the number, the type of donut, or the order, and it may communicate an entirely different message.

If a donut shop offers just 20 different types of donuts, and a message is comprised of 12 donuts in a specific order, then we’re talking more combinations than you could count in a lifetime! Not to mention other possibilities like ordering a coffee or asking about donuts not on the menu, which could have significance as well.

Basically, there’s a lot of possible ways to encode a message.

The recipient of the message may be behind the register, or may simply be enjoying his coffee at a nearby table. How would one even know? They wouldn’t, that’s how.

Should we be afraid of donut shops?

It’s all too easy to be afraid these days, with the news heavily focused on terrorism and school shootings, with the Internet turning every local story global.

Statistically, it’s unlikely that you will die due to a terrorist attack or another tragic event, particularly one related to donuts. The odds are in your favor.

As for the donut shop, just because a coded message may be delivered while you’re munching on a bear claw doesn’t mean that you’re in danger. The donut shop would be an asset, not a target. It may even be the safest place you can be.

So sit down, order a dozen donuts, maybe a cup of coffee, and enjoy your day. And please, leave the donut crackin’ to the authorities. They’re professionals.

 

(I am available to write for The Onion or Fox News.)

Memories from VMware’s Hosted UI

I wrote a tribute last week to my old team at VMware, the Hosted UI Group (aka HUG). These people were like family, and through their hard work and dedication, mutual respect and insane depth of knowledge, they built some amazing products, Workstation and Fusion being just two of them. I was so proud to be part of this team and so sad when I heard their group had been axed.

I shared my point of view on just a few of the things that made the team great. Tried to keep it short, and didn’t know who would read it, but as I write this, over 57,000 people have read my tribute, and many have shared their thoughts on the team.

Since then, our team, what we’ve been referring to as Ghosted-UI, has been out for a couple dinners, drinks, trying to figure out where everyone will end up, trying to figure out where poker’s going to be next, when the next good movies will be out, and, actually, still discussing bugs and thoughts around Workstation and Fusion. Okay, maybe we haven’t let go yet.

So here’s what I’d like to do now. I’d like to share some thoughts and pictures from a few people in our team about what made our team great, and share some comments from some of our users. Keeping it positive here.

Hosted UI Musings

Jocelyn Goldfein

Before Jocelyn left for Facebook in 2010, and then got to branch out on her own, she was the manager of Hosted UI. In fact, she’s the one who hired me back in 2004, and remained a mentor to me. My first job out of school (actually, hadn’t finished yet), and she took a chance on me, bringing me on board and helping me learn the ropes, learn to build myself up. Even paid for some driving lessons (I didn’t have a license back then).

There was a part of that that I never thought she’d have remembered, which she shared with us on Facebook:

Ok, I can add *one* thing. What Christian doesn’t mention about his aforementioned first day of work is that he anxiously showed up at 8am, in a collared shirt and slacks, nervous for his first, grown-up, corporate job.

He then got to cool his heels in the lobby for an hour waiting for the next person on his team to arrive (which was probably me around 9 or 9:30).

He immediately bonded with the team, came back the next day in jeans at a reasonable hour like 10am, and the rest, as we say, is history. 🙂

Jocelyn, with a real family of her own, shared her thoughts on what made us a family.

I 100% experienced the team as family.

To me, video games were the least of it. We were united by our shared sense of mission and care for what we were building and the community of developers and admins who used it. Our commitment to the kind of software we wanted to build and the way we would build it. Gamely celebrating each other’s lifecycle events whether that was a 21st birthday or a surprise baby shower for me which was the first event of its kind for most of the attendees. 🙂 while I haven’t stayed in close touch with everyone in the 7-8 years since I became less involved w/ the team, I’ve attended weddings, doled out career advice, helped with job hunting, new parent advice, you name it. IOW, I haven’t been there all the time, but I’ll absolutely be there when I’m needed.

For me, this team emphatically represents the possibility that you *can* form very close and lasting relationships with work colleagues, without them HAVING to also be social connections. For Christian it was both, but I don’t think I was the only one for whom it was not friendship… but still family.

When I asked for additional thoughts for this post, she brought up part of what made our products so consistently high quality, even 12 major versions in:

I feel like some of our long term rearchitecture/cleanup efforts deserve highlighting. It’s hard to have the discipline to do those. It’s not sexy or fun for the engineers, and marketing could care less b/c it doesn’t drive sales. But we pulled off some big ones b/c we had the team commitment and will to do it.

James Farwell

James (LinkedIn) joined Hosted UI in 2007, and spent most of his years since working on Fusion. He’s still with the company, just in another role, but is very much a part of our team. In a Facebook post, he shared some of his thoughts that kind of summed up our work days:

The simultaneous technical breadth and depth of this team was always stunning. You could walk past an office where 3 people were having a design discussion about how to do some complex asynchronous task while respecting the quirks of the OS X and GTK run loops and Win32 message loop. Or have a debate with someone about how best to model and manage modal dialogs in a generic fashion while still having the application “feel” like it was supposed to on each respective platform. I can’t stress that enough, so much love and care was put into having each application “feel” like a Windows app or “feel” like a Mac app despite having so much shared code. And as much ribbing as we gave each other about the other platforms, there was always so much respect.

And then you’d all go out to dinner and talk about video games.

Lee Ann Rucker

Lee Ann (LinkedIn) also joined Hosted UI in 2007, working on Fusion. I remember giving her an interview, poorly (that is, I sucked at it — I was pretty new to interviewing). She was a fantastic member of the team, really knew her stuff.

When I asked for thoughts on the team, she shared why she stayed with this product so long: Our users.

This is why I did it – because our users appreciate it. I dropped a line to the blind Fusion user [who she heard from after the news broke last week — Christian] and got this answer:

> “Hi Lee Ann. Thanks for taking the time to write, and I’m sorry to learn that you and others who have done such a good job with Fusion have been let go.
>
> It sounds like VMWare has lost a lot of institutional knowledge, and Fusion is the only accessible VM solution there is.
>
> Thanks for thinking of your blind users, many of us really appreciate all you have done.”

Jason Kasper

If you’ve used Unity on Linux or Mac, you’ve used Jason’s (LinkedIn) work. He was a remote employee, so we didn’t get to see him as often as we liked, but we chatted on IRC daily.

I did not grow up with nerd friends who were like me. I spent the first period of my life working whatever I could find in retail stores and then in corporate IT, and I definitely didn’t fit in there. But you guys… you’re all like me! Like, there’s no pretense and there’s no trying to fit in. It’s just always felt like home and family when I’ve been able to spend time with you guys.

I know it’s going to sound sad and sappy and whatever, but I just wanted to tell you guys how much you have meant to me and how much you continue to mean to me. You all have been the best 8 years of my life, personally and professionally. I love each and every one of you. And I’m going to miss being able to hang out with you in person immensely. *hug* =:)

We’ll miss it too, Jason, but are going to drag you out here kicking and screaming, one way or another.

Sujit Polpaya

Sujit (LinkedIn) was a newer member of the team, and moved to the team after I left. I’ve gotten to know him through team outings, and am glad I had that opportunity.

My tenure in the Hosted UI team is significantly less than many of you guys, but I share the pain. By far this is best team I have ever worked with – amazing people and products. I would have completed 4 years at VMware on April 30, which is just about a month after my termination date. I was looking forward to this 4-year milestone. Oh well…

Richard Bailey

Richard started off as an intern in Hosted UI, and then became a full member of the team. He left a few years back, but like many from Hosted UI, we still keep in touch on IRC, Facebook, and Twitter. He had some really nice thoughts to share with us:

The Hosted-UI Group set the gold standard by which I have judged all the teams I’ve worked with since I left (2012). We built an open environment that celebrated individuals’ strengths and supported each other’s weaknesses. We weren’t all hanging out on the weekend together (though many were) but it didn’t matter because we all cared for the product and wanted to see it succeed.

There was a dramatic breadth of technical skill (from deep kernel hacking to amazing UX intuition and user focus) and very little ego. It was an amazing place to learn post college and the best introduction to industry I could have imagined. I’m devastated to see the team disbanded but hope that the core of how that environment functioned follows each of the team as they spread out to whatever amazing things they decide to pursue.

On a more personal level I owe a lot of my adult life to the situations that arose from taking the full-time offer. Without coming to HUG I would have not met many of those who are now my closest friends, would not have started rock climbing (which was key for me to *finally* get healthy), and would not have made the connections necessary for my subsequent jobs which I have also loved. It would be an understatement to say that this team, and the internship that pulled me in, significantly altered the course of my life.

For those that were laid off you can pretty much call on me for anything and I’ll do what I can to help regardless of whether or not we overlap: that’s how family works. I’m sorry this happened but I trust you’ll be okay.

James Lin

James (LinkedIn) was one of the first people I met when I joined VMware. He’s a legend. The guy knew the codebase inside-and-out, probably better than most of us, and plowed through bugs and features like nobody’s business. He worked on the Windows side on Workstation and Player. He saw a lot of change in the company and even in the team, and I always pictured him single-handedly holding the products together until the very end, if it came down to it.

He shared his view of what made the team great and how he saw his work over his time at VMware.

I’ve been in VMware’s Hosted UI group (“HUG”; could there be a more appropriate name?) working on Workstation for almost 12 years.  I’ve seen a lot of people in HUG come and go (although I think not quite as many as in other groups), and while some of them tried to pull me away to join other companies, I never really wanted to leave.  I loved our product.  Even after nearly 12 years, I never got tired of fixing bugs; I saw each bug as a usability problem for customers.  Repetitive bugs challenged me to try to prevent future recurrences.  At VMware, there was always something for me to work on and always something new for me to learn, and it never got boring.

And I loved my colleagues too.  I tried my best to help them when possible (by answering questions, offloading bugs, reviewing their code, implementing helper functions they needed, writing scripts to simplify drudgery, buying unhealthy snacks for them from Costco) to make their lives a little bit easier and so that they’d have more time to work on things that they found interesting.  I never wanted them to leave (and jokingly threatened to kill some of them if they ever tried).

People in HUG helped me buy a car for the first time.  HUG filled two tables at my wedding.  HUG was a family, and our products were our babies.  I don’t know how I’m going to bear seeing them in the foster care of complete strangers.

Tony Fregoso

Tony (LinkedIn) was a member of our amazing QA team (a team that suffered its own layoffs a couple of years ago).He had both QA engineering and management roles during his time with us. QA was important to us on a personal and professional level. They kept the quality of our products high, and knew the products and their history inside-and-out.

Tony shared his memories and thoughts with us:

When I look back at my time at VMware the one word that always comes to mind is family. Beyond all of the incredible technical feats the teams achieved it is all dwarfed by the shear strength of the bonds that I formed and saw formed with the people that I worked with at VMware.

Even as the company grew and changed HUG, Desktop QA and the greater Desktop Business Unit retained much of its core identity because of the people who worked within it. The passions that were shared for the products was equally shared for the people. In the valley where it is the norm for people to change jobs ever 2 years we had a team that clearly pushed against this. Between the Dev and QA teams we had some of the most tenured members in the entire company. This happened for many reasons, a shared passion of quality, love and dedication to the products we worked on and the close bonds we had with each other.

I am thankful to VMware for bringing us all together in the way that it did, regardless of how things ended. The fact is that the strengths of the bonds that we formed are far greater and are something that will always exist.

Family

Our users had a lot to say

I was surprised by the outpouring of love from our users. I want to share a few select comments from my earlier blog post:

Bruno Kerouanton said:

I just wanted to congratulate you and all the team on the fabulous work you did. I bought my first license for VMware Workstation Linux 2.0, back in 2001 ! And use Workstation and Fusion on a daily basis (See my latest blog article on http://éé.net/ak6), it’s just a critical part of my infrastructure!

So I’m sad for you. And I just wanted to say I love you for what you made available for so many people worldwide 😉

jorgedlcruz said:

I’m a VMware vExpert because I did my Home Labs using Workstation, or even Fusion sometimes, you helped so many Companies out there, not just power users, I saw some environments using Workstation at really high scale, insane but working!

You guys did just amazing job all this time. I just can say, thank you and good luck!

Jeff:

Its really no wonder now, why apps like VMware Player and Fusion just worked so well despite doing really complicated things. Kudos to your team for really being the best champions of your product and making the computing world a much better place (this is what happens, for anyone else interested, when keeping developers happy and engaged takes precedence over keeping salesmen happy and engaged).

skimans:

Big thanks to you all 🙂 I was one of those early users. This software changed life of many people for better. Sorry to hear bad news. it’s bad move to shut down this products and your team. This software is living ad for whole company, for many of us first step into virtualisation.

R Warder:

Great product that changed the way the world works – testing and development was different before VMWare. So slow. This article was great insight into the team that made our lives better. A sad announcement but best wishes to a talented group of people.

velviavelvia:

Thanks for this tribute. I was also at VMware for 9 years, starting on the Vmkernel team that built one of the first releases of ESX, and saw it grow from a team of 200 in Stanford Research Park, with personal introductions of every new employee, and pool dunkings for folks getting married, to a big corporation of over 10k. Your team was one of the most dedicated and legendary teams at VMware. So sad to see it go.

Eddie:

I’ve been a loyal Fusion user since 2008. Fusion is what convinced several colleagues of mine to go to the Mac when they got fed up with Windows machines. I proudly buy each and every new-release license(s) because of the phenomenal quality and support that was given.

When I had problems with Fusion/Windows, the engineers actually invited me to their labs in Silicon Valley and sit next to them to work the problem out. That was support (to me) that was unheard of. I was in awe at their commitment and pride in what they did.

Gary Jones:

Absolute legends , such sad / infuriating / inexplicable / perplexing news. I’ve used VMware since day 1 and never ever looked back. Without this software I’d never have progressed anywhere near as far in my career as I did.

Kermit Vestal:

Ooooh nooo! Say it isn’t so. I was jaw droppingly amazed when I saw 1.0 and could see the VM of everything was the future of everything. Its been one of my mainstay tools ever since. Many similar free and not free tools have followed since, but none compares to the feature qualities and reliability of Workstation. Its always been ahead of its time and now we know why. So sad its been stripped of its culture and I fear its future. Thanks for telling us the rest of the story.

Thank you, everyone.

Pictures speak a thousand words

We dug around and found a bunch of pictures from our time at VMware that I thought would be fun to share.

We liked food. We had our own “Unhealthy Snack Program,” where we’d keep our group stocked with candy bars, beef jerky, sodas, etc. Sometimes you need a little sugar and caffeine when you’re battling some crazy bug. I wish I had a picture of this, but it was glorious.

We once won a waffle maker at Dave & Busters, during a group outing. Here’s Keith, making some yummy waffles for breakfast. He never made me any…

 

Picnics were always a fun way to bring the team together. Often, former members of Hosted UI would take the opportunity to show up, eat some hot dogs and catch up with the rest of us. Great way to spend a day, though we ended up talking shop more than we probably should (except for that one time we climbed trees for hours, just because we could).

 

We’ve been playing poker for years. Just casual games, nothing fancy. We’d order a pizza and play for a few hours, share some laughs. Really, we were just like the pro poker players, except a 2/7 won way more often than it should have, and things like this kept happening:

 

The table won more than I did.

 

Not all of us were gamers, but a bunch of us got together most weeks to play games of some sort. Video games, card games, board games, what have you. Smash Bros, Mario Kart, Mario Wii U, Kirby, and the Rayman games were personal favorites of mine.

This was actually on the day we IPO’d! We just got a Wii and had set up the projector for some tennis action. Man, that was a long time ago…

 

If you were getting married, or just got married, you were going in the pond. It was an old VMware tradition that we fully embraced. We amped it up a bit, though, with the introduction of costumes. You know, because your clothes were all wet, so we helpfully provided new clothes!

 

 

 

 

Birthdays are something to be celebrated! Back in the day, we’d trick people by inviting them to a meeting and surprising them with cake. Eventually people came to expect it, so then it just became cake. Oh, and an amazing birthday candle that would shoot up fire like a torch for a minute, spin around, and sing.

True story: I had my first drink at VMware, in a surprise birthday meeting. And then my second. Jocelyn insisted. I’d never been so much as buzzed before. I remember Jocelyn coming in, asking me to do something, I don’t even remember, thoroughly enjoying watching me struggle to even understand what was going on. Good times.

 

There was that one time we all got dressed up, just because. It was kind of an inverse Casual Friday. To start off, here’s some great group photos of Lee Ann on Fusion Engineering, Roshini on Fusion Performance, and Jessica on Docs.

 

In order from left to right: Surendra, Roshini, Steve, Lee Ann, David, Michael, and James. (Shame we didn’t have the whole team in this shot.)

 

Okay, terrible pun alert, straight from the Facebook post: “At VMware, our managers go APE for new releases!” (Another awesome win from Dave & Busters!)

 

Pets were always welcome in our office. This is Bodie (as a puppy — it’s been a while). We had other dogs, sometimes cats. A duck followed me into the building one day.

 

 

Can you ever truly leave the team? Might come at a price… DUN DUN DUN. (I found my entire office covered in this stuff, shortly before my last day at VMware.)

 

 

 

We once got these plasticy bookshelf things made from I think recycled milk jugs? Someone realized that they could be disassembled and reassembled, so our team, always eager to end the day on a productive note, set off to build Tetris bookshelves.

 

 

 

There was that time when we were trying to get into a company-owned pinball machine that accidentally got reset from free mode to pay mode. We weren’t about to pay $0.25! So, we spent about 3 or 4 hours trying to pick the lock with instructions from the Internet and good ol’ Hosted UI ingenuity! With the lights off. Using flashlights. Inside an office room. I swear, we’re usually smart people (P.S., it did not work. We gave up and went home after 1AM. The following contraption is what we built to try to pick the lock.)

 

 

Oh, and that time we decided our IRC channel could really benefit from Microsoft Comic Chat. We had this up and running on a dedicated screen 24/7.

 

I’ll probably update this over time with more thoughts and pictures as we find them.

Thanks for walking down memory lane with me, and for all the support you’ve shown Hosted UI over the past week. 🙂

A Tribute to VMware Workstation, Fusion, and Hosted UI

Updated February 2, 2016: Once you learn about our team and who we are, come take a trip down memory lane with us!

Yesterday morning, the Hosted UI team, responsible for VMware’s Workstation and Fusion products, woke up to find themselves out of a job. These products, despite being award-winning and profitable, are probably not long for this world.

I was not directly affected, in this way at least, as I had already left VMware in 2013 to work on Review Board full-time. However, many of my closest friends were, and a product I spent 9 years of my life on may have seen its last feature.

I could talk all day about how I think we got here, losing this amazing team and these fantastic products. I could point fingers and lash out at those I blame. I could talk about how furious this all makes me.

Instead, I’m going to talk about the team and what we built — and I don’t just mean our products.

Let me tell you about our team

I began working in Hosted UI on August 23rd, 2004, as a bright-eyed 20 year old freshly dropped out of college. Back then, it was a small team full of amazingly bright and passionate people, working days and nights to build a product they believed in.

The culture at that time within VMware was just so fun and energizing. People wanted to be there, and were proud of their work. Features were brainstormed over games of foosball or DDR, designs discussed over free lunches and beer bashes. In the evenings, we’d order dinner in and watch Simpsons, or whatever was on.

Company culture changed over the years, becoming more corporate and stiff, but not Hosted UI. We’d work all day, with the occasional interruption for YouTube videos or some laughs, and at night we went out and had some more. Poker nights, movie nights, video game nights. Dinners out together, sometimes several times a week.

Many people came and went over those years. The team changed, though, for a software company, a surprising number remained until the very end. Even those that left kept in touch, joining for poker nights or dinners here or there, coming to the dunkings (if you were getting married, you were going in the pond), birthday celebrations, and reunions. We formed alumni lists and kept in touch. We hung out on IRC outside of work.

Through deadlines and downtimes, stresses and celebrations, our team worked and played hard. We were dedicated, passionate, and if you’ll allow me, we were damn good at what we did.

I left this team two years ago, but it hasn’t really felt that way. I still saw them almost every week. Our team didn’t have to be in the same building or even the same company to stay a team.

Hosted UI may no longer exist at VMware, but that’s really VMware’s loss. They lost one of the most dedicated teams they could ever hope for, the kind of team you can’t just hire again.

We built some amazing products

Workstation

VMware Workstation was the first VMware product (back then, it was simply known as “VMware.”). At a time when dot-coms dominated the Super Bowl and Amazon was all about books, VMware Workstation was letting pioneers in the Linux world virtualize their Windows desktop so they could run Microsoft Office instead of StarOffice.

This product evolved over the years with over 15 major releases, and more features than I can count, running on every flavor of Linux and Windows. It did this without falling prey to the bloat of most long-running products, as we focused not only on making it a more powerful product but also a more usable product.

Workstation made it easy to run complex development and testing scenarios, creating and working with several virtual environments all at once across any number of host computers. It integrated your virtual desktops with your host desktop. It let you take snapshots at different moments in the lifetime of your VM, and jump between them at will. It helped you catch defects in your software through remote debugging and CPU/memory record/replay capabilities, it helped you test complex network setups with virtual LAN devices, and it worked as a powerful front-end for VMware’s Server, ESXi, and vSphere products. And, in the end, it also helped you simply run your Windows programs on Linux, your Linux programs on Windows, or whatever you wanted.

 

Internally at VMware, Workstation was also seen as an indispensable product, helping other teams test features and devices that would eventually become selling points on the more high-end vSphere product releases. With Workstation’s ease-of-install and ease-of-use, people could get set up in minutes and get right to work.

We loved our product. This was our baby. We took input from marketing, management, sales, customers, and so on, but in the end, we were given a lot of creative liberty over the features and design. We were also given time to address technical debt, helping to get our codebase in shape for future challenges.

I don’t know how many awards we received, but I think it was a lot. I do know that we had so many users who loved the product we poured our souls into. That meant a lot, and kept us motivated.

It was, let’s say, a challenge getting some parts of the company to really care about the product. Workstation made a lot of money, but not the hundreds of millions the company would have preferred. This, I believe, ultimately led to yesterday’s sad outcome… Still, I’m very proud of what we built.

Fusion

Workstation was a power user product built for Linux and Windows. In 2007, its sister product, Fusion for Mac, was released. This focused more on consumer usage, helping people run Office and other Windows apps on their Mac.

At the time, Apple had just moved to Intel processors, and were touting the ability to dual-boot between Windows and MacOS X, using a feature called Bootcamp. Fusion offered a better way by letting you run Windows and MacOS X at the same time. It was popular amongst students who needed to run Windows software for class on their shiny new MacBooks. It was popular amongst developers who needed to run or test Windows or Linux environments while on the go.

Fusion was a very different product in some ways than Workstation, but it was also very closely related. While it didn’t focus on many of the power user features that Workstation offered, it did take many of those features and reimagine them for more casual users. It also shared much of the core code that Workstation used, meaning that features could more easily be ported across and bugs fixed just once.

Fusion was a reimagining of what Workstation could have been, built for a different time and a different audience. Like Workstation, it was also built by a group of very loyal, dedicated, brilliant people, the Fusion segment of Hosted UI.

While I never worked directly on Fusion, I did get to see features I built for Workstation make their way there, and watched as our users got to try them for the first time on the Mac. It wasn’t the product I devoted my time to, but it was one I loved, and one I still use today.

And all the others

Our small team has built quite a lot over the years. Along with Workstation and Fusion, we’ve also built:

• Player: A slimmed-down product for simply running and interacting with VMs, without all the UI of Workstation
• VMRC: Originally a browser plugin and an SDK for embedding virtual machines in your browser or other applications (which was transitioned to one of the teams behind ESX a couple years ago and reworked into a native VM console app launched from the browser)
• Server: A free product built from Workstation that offered remote VM hosting and management)
• WSX: A web-based service for running VMs natively in your browser from anywhere
• AppCatalyst: A developer-focused, API-driven development and testing service that works with Docker

I’m pretty sure there’s more, but those are the highlights.

These, along with Workstation and Fusion, were built by a team typically no larger than about 20 people (at any given point in time).

We did good.

Time for the next adventure

VMware lost a lot of amazing people, and will be feeling that for some time to come, once they realize what they’ve done. It’s a shame. As for our team, well, I think everyone will do just fine. Some of the best companies in the Silicon Valley are full of ex-VMware members, many former Hosted UI, who would probably welcome the chance to work with their teammates again.

Workstation, Fusion, and our other products may survive in maintenance mode, or they may disappear. They may continue under a new team. It’s hard to say at this point what will happen. What I can say is that no matter what happens to them, they had an amazing run, and are something every one of us can be proud of the rest of our careers.

And we can be proud of the team, the friendships, and the strong bonds we built, now and through our next adventures.

Updated 27-January-2016 at 23:31 PM: Wow, this went viral. As of right now, we’re looking at around 40,000 unique viewers. I wrote this as a tribute for our team, and am amazed by the reaction it provoked. Everyone who loved our products and reached out to us to show your love, thank you. It means so much to us. Keep them coming!

I want to be clear that I have not worked there in years and do not have inside knowledge on what will happen to these products. I updated part of the post to make that a little more clear. VMware claims they’ll continue to exist, and I really hope that’s the case. I like to think what we built will continue to live on, and I hope VMware does it justice.

You’re not safe on the Internet (but you could be)

It’s a wonderful Friday evening. You’re out enjoying it with some friends, eating dinner at a classy Italian restaurant, telling stories and laughing together as you share a delicious bottle of wine. It’s the perfect end to the week.

As dinner wraps up, you hand the waitress the first card you grab from your wallet, a debit card, and don’t think twice. Moments later, she returns and asks you, quietly, if you have another card they can try. Looking at the debit card in her hand, you put two and two together, and a sinking feeling creeps in.

You pick up your phone and check. Sure enough, your account has a $0 balance. You just deposited your paycheck last week, and have been careful to keep a reasonable balance in there. And it’s gone. All of it.

You can’t begin to understand what happened, as you frantically call the bank, your night utterly ruined. But someone knows. The one who drained your account. The one who entered just the right username and password. The same password you use on a dozen sites. The same one you used to order flowers three years ago on a local boutique’s site. The same site whose password database was quietly hacked last week.

The Internet is a wild place

Most people on the Internet only see the tip of the iceberg. They’re on Netflix, Google, YouTube. They’re playing mobile games, ordering from Amazon. The Internet is like a giant mall with the best shops and arcades.

There’s more to the Internet than you may see. Darknets, where identities, weapons, drugs, and the darkest of pornography can be bought and sold. Cyberwarfare and espionage between countries of all sizes. Enormous “botnets,” or networks of compromised computers just like yours that are used to attack networks and crack passwords. Teams of hackers who work to find vulnerabilities in sites or in people and exploit them for amusement, financial gain, or just to make a statement.

This isn’t a reason to fear the Internet, to fear shopping online or visiting new places. This is a reason to respect it, and to be safe.

The line of fire

“But nobody will come after me!” you might think. “I’m not important. Who would target me?”

The problem with that line of thought is that it assumes a person is going after you specifically. That’s often not the case. Hackers and botnets go after many, many websites. They’re looking to hit the motherload. For instance, here’s some of the bigger sites hacked lately, and how many people were affected:

• Steam – 35 million
• Evernote – 50 million
• Home Depot – 56 million
• Target – 70 million
• JP Morgan Chase – 76 million
• PlayStation Network – 77 million
• Anthem – 80 million
• eBay – 145 million

Ever use any of these? Me too.

So what happens next? Well, automated systems will harvest the results and begin trying these combinations of usernames/passwords on all sorts of different sites. Google/gmail, banks, dating sites, anywhere. And how big are these botnets? They can reach up to the 10s of millions of computers.

You are not specifically being targeted, but you’re in the line of fire. And this is going to keep happening, over and over again.

So let’s protect you from this. I’m going to teach you about three things:

• Using passwords safely
• Two-factor authentication, a second layer of protection and alert system
• Identifying and ensuring secure connections to websites

And in case you’re wondering, yes, you are the target of my post. So keep reading.

Passwords: Your first line of defense

Most people on the Internet treat passwords like they’re a cute little passphrase to get into a clubhouse. We’re trained by our computers to pick something memorable to log us into our desktops, a code that “protects” you from others in the house who might want to check your e-mail. Much like a standard lock on your door protects you from your neighbors simply walking in.

Nobody ever really teaches us properly. It’s common to use your dog’s name as a password, or your birthdate, or something equally easy to remember and crack. It’s also common to use the same password or set of passwords on many different sites and services, which is how our fictitious Friday night was ruined.

This is extremely important to get right. Here are the rules for protecting yourself using passwords:

1. Never use the same password for more than one site.
2. Pick a long, strong password with uppercase and lowercase letters, numbers, and symbols, without any dictionary words.

That’s basically it. Seems simple enough in theory, but how do you keep track of all those passwords? You’d probably have 50 of them!

Don’t worry, there are tools that make this super easy.

1Password

This is one of my favorite tools for staying secure.

1Password is a tool for keeping track of your accounts and generating new passwords. It works with your browser and remembers any password you enter, and makes it really easy to fill in passwords you’ve already entered.

When you’re creating a new account or changing passwords, it’ll help you by generating strong, secure, nearly uncrackable passwords. For example, here’s one it just made for me: wXXgVzb8Zp(zwmjG7zBGkg=iT.

It’s available for Mac, Windows, iPhone, iPad, and Android. It’s free for iPhone, iPad, and Android, and costs only $35 for Mac and Windows (which is a bargain for what you’re getting).

Let me show you how it works.

I’m about to log into an account on Facebook.

Instead of typing my login and password, I just click that little keyhole icon next to the address bar, which will pop up any 1Password entries I have for Facebook.

Once I click “Facebook,” it’ll fill in my username and password and log me in. It’s just that simple.

When you’re signing up for a new account, use the Password Generator, like so:

Once you create the account, 1Password will remember the password for later. Look at that thing. Nobody’s cracking that!

This all works for any site, and even works on your iPad/iPhone:

1Password is great for more than passwords. It can keep secure notes, information on your credit cards or bank accounts, or really anything else you have that you want available but locked away.

In order to access your stuff in 1Password, you only need to remember a single password of your choosing. Make sure this is a strong one, and that you don’t forget it! Write it down if you have to.

Buy 1Password and use it. Look, $35 is nothing compared to the potential fallout of being involved in the next several major security breaches.

LastPass

LastPass is an alternative to 1Password, and is great if you’re an Android user. Usage is pretty similar to 1Password.

I don’t personally have a lot of experience with LastPass, but a lot of people love it. You can learn more about it on their site.

Pen-and-paper password journal

I’m sure you’ve been told before that it’s a bad idea to write down your passwords, am I right? Afterall, if you write them down, then gee, anyone can get them!

That’s not entirely true. The fact is, you’re more at risk reusing one or two weak passwords on the Internet than keeping dozens of strong passwords written down on paper in your home.

Let’s be clear, this is not the best option, and if you’re going to do this, keep it secret, keep it safe. Still, it’s better than not having strong passwords. If at all possible, use 1Password or LastPass, but if you absolutely must, write them own on a dedicated journal that you can keep safe somewhere. Don’t lose it, and always use it for every password.

Two-Factor Authentication: Second line of defense

You’re now using stronger passwords, and you have friendly tools to help manage them. Good job! The next step is making sure that only you can log into your most important websites.

Many sites and services (Google, Apple, Dropbox, Evernote, Bank of America, Chase, and many others) offer an extra security layer called “two-factor authentication.” This is a fancy term for “We’ll only log you in if you enter a code we’ll send to your phone.” When enabled, these services will require something you know (your login/password), and something you have (your phone).

Let’s take Google, for example. You can set things up so that after entering your username and your brand-new secure password, Google will send you a text message with a 6-digit code. Once you receive the text (which only takes a second), you’ll enter it on the site, and you’ll be logged in.

Now why would you do that? To prove that you are the one logging in, and not someone who’s figured out your password. The cell network’s going to make sure that text is only going to your phone, and you’re going to prove it’s you logging in. (Some services will require that you use a specialized app, or a hardware device that fits on your keychain, but most will work with text messages.)

Imagine someone did get a hold of your password, and tried logging in. You’re still going to get that text, but that person will not. He/she won’t be able to log in as you. You’re safe! It’s also going to be a dead giveaway that your password was compromised. You’ll want to change it right away.

Basically, this is both your gated community and your alarm system.

This is pretty easy to set up at most places. Here are some guides:

• Apple
• Bank of America
• Blizzard
• Dropbox
• Evernote
• E*Trade
• Facebook
• Google
• Microsoft Office 365
• Outlook.com
• PayPal
• Snapchat
• Steam
• Twitter

You can find more at twofactorauth.org. Just click the icon under “Docs” for any service you use that’s green.

I’ll be honest with you, this will feel unfamiliar at first, and you might be tempted not to do it. Trust me, though, this is worth turning on for as many services as possible. You’ll be glad you did next time one of these companies announces a security breach.

Identifying and ensuring secure websites

Let me briefly explain how the Internet works.

When you connect to a website, the browser will usually try to access it first over the “HTTP protocol.” This is the language that browsers and web servers speak. This communication is in plain text, which means anybody that listens in can read what’s being posted. This is sort of like handing a piece of paper to someone, and having them pass it along to the next person, and so on, until it reaches its final destination.

That’s very bad if you’re sending anything confidential. Passwords, for instance. It’s important that you learn to identify when you’re on a secure website.

You know the address/search bar on your browser? Look to the left. If you see http://, or you don’t see anything but an icon and a domain name, you’re on an insecure website.

However, if you see https://, or a lock icon, or a green banner, you’re good! This is using HTTPS, an encrypted connection, meaning that nobody in-between can listen in. That’s more like writing your letter in gibberish that only you and the final recipient understand.

For comparison, these are secure:

This is not:

Always look for these before filling out any forms. If it’s not showing a green banner or lock, you don’t want to give the site any sensitive information.

If you see a green banner, it’ll show the name of the company or organization. This is showing that the encrypted channel and website have been verified by a “certificate authority,” an entity that issues certificates for these encrypted channels. It means they’ve checked that, for instance, ally.com is owned by Ally, and not by someone pretending to be Ally.

If you click the banner or the lock icon, you’re going to see some more information about the connection. Most of this will be highly technical, but you should see some blurbs about who verified the authenticity of the site, and some information on the organization owning the site.

Most websites these days are moving to encrypted HTTPS connections, and most will automatically redirect all requests from HTTP to HTTPS. This is good, but you can go a step further and have your browser always start out using the HTTPS connection whenever possible. This takes almost no effort, and is worth doing.

This is done with a browser extension called HTTPS Everywhere.

If you’re running Chrome as your browser, simply install it from the Chrome store.

If you’re running Firefox, install it from the Firefox add-on store.

Did you do it? Great, you’re done! You’re now a little bit safer on the Internet!

Putting it all together

I threw a lot of information at you, but hopefully you’ve learned a lot and will put it into practice.

So let’s summarize. If you follow the above, you’ll:

• Be at less risk for identity and financial theft the next time there’s a major security breach, since your passwords won’t be shared.
• Be alerted when someone tries to log in as you on any service with two-factor authentication enabled.
• Have passwords strong enough to be unguessable and nearly uncrackable, for all sites and services you use.
• Know how to identify secure websites, so you don’t leak passwords or other private information to anyone who’s listening in.
• Automatically connect to the most secure version of a website whenever possible.

Not bad for a little bit of work. Hopefully by now, you realize that this does matter, because you, I, and everyone else really is a target, simply because we’re all part of something large enough to be a target.

So pass this around. Tell your friends about what you’ve learned. Educate your kids. Stay safe on the Internet.