On popular events and the efficacy of registrations

Codemash - probably the single best regional development conference in the country - sold out of 1200 tickets in 20 minutes.  This is pretty impressive, but hardly unheard of.  ShmooCon, the DC security conference, sells out in a few seconds every year. and has gone to a lottery system to distribute tickets. This is not optimal because many who want to go and should go are not admitted by pure bad luck, making the conference worse overall.  While degradation in quality is an effective way to reduce queue length, it isn't one that anyone really wants.

I am fascinated with the economics and psychology behind popular events and their queues.  Generally, for something like a concert, you will drive the queue length down with cost.  You want to see Madonna?  Fine - $350. Too rich for your blood? Good - we had too many people anyway.  This works for a lot of entertainment topics, actually, since there is no moral standard for admittance.

Colleges are another story.  A good college will have an abundance of admissions, but only a few will be accepted.  Private schools will filter with cost as well - but is this a good idea?  Do you want those with the most money, or those who have the best chance for success? Those two items won't always overlap.  The Objectivist seminar that used to be in Virginia every year had a good solution: they filtered with high cost but had a scholarship program.  To apply for a scholarship, you needed to do a LOT of writing, and it had to be GOOD.  Few went to the trouble, but those who did REALLY wanted to be there. I know, because I was a recipient in 1997.

But how to reduce the queue for something like Codemash? Eventually something like a lottery will have to be instituted, because next year noone trying to register more than a few people at a time will be able to get tickets. But see, that is a problem, as this is a conference where people who really WANT to be there, should be there.  High prices have a similar problem - in general the community is not short on funds so that will probably do nothing except tick people off. (Although a charity could get involved which would be neat).  Even then, do we really want to put the con out of the reach of students? Early registration - effectively reserving space WAY in advance - is another possible solution. I am sure there are other options - guess I need to get out the queuing textbook from OSU.

They aren't kidding about that 'enable exceptions' thing

In the default templates for WinJS Windows 8 applications, there are two lines that are easy to ignore:


    // Uncomment the following line to enable first chance exceptions.
    // Debug.enableFirstChanceException(true);


They aren't kidding.  I was doing a little work with the Pastebin API (shh, don't tell anyone) and had failed to declare a variable.

Over and over, I would run it and have no idea that something was wrong.  I would have to set a breakpoint and know where to look to find errors.  It sucked.  I am too used to an IDE.

Then I remembered those lines, uncommented the Debug member there, and was good to go.  It seems painfully obvious now, but it didn't before and if I can help someone else not pull their hair out, we are all the better.

Generally, though, I am not sure how I feel about this.  It seems a lot like On Error Resume Next in VBscript, and we all know how THAT turned out.

Notes from my Pentesting ASP.NET talk for DODD today

As promised, here are the relevant links to things I talked about at the OWASP talk today.

Thanks to DODD for inviting me out and for the nice certificate! Oh, and the food was awesome - one sure way to get speakers out there.


Got a cub scout in Simon Kenton council? Cross stitch?

The council patch is DMC 307

The Den patch is DMC 939

The international Scouting patch is DMC 550

The Pack Number is DMC 817

The 100 year ring is DMC 310

Just a PSA from your friendly neighborhood scouting family.

Want some popcorn?


Dual boot Windows 7 and Windows 8


When Windows 8 released, I was waiting.  I am not usually the first in line for OS releases, but this time I had a vested interest. I have a book in the works, and this release was an important part.

I was ready with VirtualBox, Windows Virtual PC, and a spare laptop (in case I needed to install on the metal). When the ISOs were available, I was first in line, with a fast connection, and I did the Pokemon bit – gotta get ‘em all.

VirtualBox refused to honor the 64 bit virtualization of my HP XW6200. Aaaand, so did Virtual PC. And guess what – the spare laptop I had was 32 bit too. I was stuck.

Except I had my main laptop, which was 64 bit and had Grub and a Linux partition.  Maybe, just maybe I could instead turn it into a dual booting Windows 7 / Windows 7 laptop.  This post is about how I did it.

Getting rid of Linux

The first time I had to do was get rid of Linux. I did this by removing the partitions that it lived on (That Wubu had made for me) and making them into an empty partition. I did this with the Disk Manager.

In Windows XP and prior, disk partitioning required a tool purchase. In Vista, Microsoft included a tool called Disk Management, part of the Computer Management control panel. To get there, open the Control Panel, change to Icon View, click Administrative Tools, and open the Computer Management panel.


This image shows my desktop right now, but the laptop had 6 partitions

  • The original Vista recovery partition
  • The C partition
  • Grub
  • Ubuntu 10
  • Ubuntu11
  • System Reserved

So I deleted the two Ubuntu partitions and Grub and made them into an empty partition. I made one on my desktop to show what I mean.


Here, I have a 250 GB unallocated partition.  I can right click on it and name it so I can be sure to get the right one when I am installing Windows 8.

Making a Windows 8 boot UBS drive

Now I needed to install – and I didn’t have any blank DVDs. (Really) I did have a 75 gig USB drive though. My laptop had the capability to boot from USB (as many do) so I decided to make a bootable USB drive.

  1. Start with a drive that you can empty (You can add stuff later if you need to).
  2. Extract the ISO to a file directory on your hard drive. Use WinRAR if you have nothing to do that.
  3. Download NovaCorp’s WinToFlash product.
  4. It runs right from the download no need to install
  5. Use the Windows Setup Transfer Wizard to move the extracted files from the ISO to the USB
  6. There ya go!

Making a Windows Partition

So I rebooted after this activity, and I got a Grub error. As it turns out, Grub doesn’t LIKE it when you delete its master boot record. I needed to load up a repair utility. Since I had a Windows 8 boot drive now, I booted to it by setting my BIOS to boot from USB, and entered the Repair menu.

From there I went to Advanced Tools, got a command prompt, and entered two commands:

bootsect /nt60 C:

and then

bootrec /fixmbr

Rebooted and then Windows 7 booted just fine.

Installing Windows 8

Installing Windows 8 was an awesome experience. I shut down Windows 7 and changed the boot partition to the USB drive again. When it came up, I had a normal Windows 8 install experience, which took about 10 minutes.

The installer auto rebooted, and I still had the bootable USB drive in. Since my BIOD was set to boot from that drive, it went back to the installer startup. I just shut down my machine, and unplugged the USB drive, restarted and the installer continued.

After installation, I rebooted to discover that Windows 8 comes with a boot manager! I get a big, neat MetroUI selection screen asking my if I want to boot into Windows 7 or Windows 8.

The Finished Product

I was stuck in 1024/786, but I had a landscape display. In a last ditch attempt, I navigated to the Display Settings, selected Advanced and then Update Driver.


Here I tried the Search Automatically feature and what do you know, it worked.

Now I have a perfectly working Windows 8 and Windows 7 partition, and I can freely boot between the two. The Windows 8 partition even has my Windows 7 partition mounted as a drive!

Nice work, Microsoft. Your work really showed on this one.

Recipe: Grilled Jalepeno Poppers

10 fresh jalepeno peppers

2oz Cream Cheese

2oz Shredded Chedder Cheese

2oz Real Bacon Bits

Pepper Grilling Rack, or carefully folded foil.


Using gloves, take the tops off of the peppers, and seed and core them.

Mix the cheeses and the bacon in a bowl.

Fill each pepper with the cheese mixture, then drop into grilling rack.

Grill on medium heat for 30 minutes, or until peppers have softened.




How I play miniatures with a 6 year old

My recent tweets about Warhammer with my son Adam have brought in a few questions, mostly: “How do you play that incredibly complicated game with a 6 year old?” Good question, that.  I can’t usually remember the Warhammer rules, so how am I expecting him to be able to get them.

The answer was a simple but balanced set of rules that I came up with merging some basic ideas from a lot of miniatures games.  I thought I would codify them here in case anyone else wants to try them with their kids.

Remember, this is VERY SIMPLE, so there is a lot of room for adjudication. A hard core gamer would find this very boring. Adam loves it, though.


Tourna is a turn based miniatures game for two to four players.


Tourna is played with miniatures and dice.  Any miniatures can be used, including non-traditional figures like Legos or plastic animals. As long as they can be isolated (for instance, a lot of figures molded to a common base won’t work), then grouped into units, they will work.

At its core, Tourma is about building armies based on an agreed number of ‘dice’ in total.  Each individual miniature, or “figure”, is assigned a certain number of dice, which represents both that figure’s attack and defense value. If both sides have the same number of dice on their side, the game is balanced and may commence.


Tourna is best played on a flat clean surface like the dining room table.  After deciding on a source for miniatures, dice values need to be assigned.

Generally, individual figures are 1 dice, and generals are 2 dice.  Vehicles or machinery are 2 or 4 dice.  For instance:

Bill is playing dinosaurs.  He has 16 basic figures and 2 generals in two ‘units’, or groups that move together. His side totals 20 dice, because 16x1 = 16 and 2x2 = 4, and 16+4 = 20.

Adam is playing Legos.  He has a tank, which we decide is worth 4 dice.  Beyond that, he has 8 mounted figures with a general (total 10 dice) and 6 gunners. 4+10+6 = 20.  The sides are even, and play can begin.

Simple game setup using Brettonians from Warhammer

Units stay together through the game, and can either move or battle.

Units may be designated as ‘shooters’ but they have a harder to-hit and damage roll. (See ‘Battle’)


Movement is measured in inches.  Distance can be scaled to your environment, and decided based on the figures you have available. 

A good starting point is to allow shooters to move 2 inches per turn, footmen to move 4 inches per turn, and mounted (vehicle or horse) to move 8 inches per turn.

Units are allowed one free reformation per turn.  They can rotate in place, or change formation either before or after they move.

Mounted units can ‘charge’ in exception to the ‘move or battle’ rule.  If the opposing unit is within range of the mounted unit’s movement, the mounted unit can elect to move to base to base contact, and then melee.


Battle in Tourna is restricted to melee and shooting.  Decide if each unit contains shooters at setup.


Units in base to base contact may melee.  All units except machines can melee, regardless if they are designated as a shooter.

The unit whose turn it is is attacking and the opposing unit is defending.  Attacking units may roll one six-sided die for each die of value they bring to the game.  Units roll to hit first, and if they hit then they roll for damage.  There is no special defense number for opposing units – only the attacker numbers matter.

Melee-only units hit on a roll of 3-4-5-6 on a 6 sided die.  They damage on a roll of 4-5-6.

Shooters (whether shooting or in melee) hit on a roll of 4-5-6 on a six sided die.  They damage on a roll of 5-6.

So, for instance, Bill’s unit of 8 Velicoraptors and one General is in base to base contact with Adam’s mounted unit.  The Velicoraptors are not shooters.  The General is worth two dice. Bill rolls 10 six sided dice for the 8 dinos and one general. 6 of the dice are 3 or higher, so he rerolls them for damage.  3 of them are 4 or higher, so Adam’s unit takes three dice of damage.  Bill can choose if that is 3 figures, or 1 figure and 1 (2 dice) general.


Shooting can only be accomplished by figured designated at Setup as shooters. They can shoot the entire length of the play area. There is no distance measurement.

Shooting is line-of-sight.  One member of the shooting unit must be able to see one member of the defending unit to be able to aim for it.  All members of the shooting unit must shoot at the same defending unit. Shooters cannot move and shoot in the same turn.

Shooters cannot shoot into a melee.

Shooting units hit on a 4-5-6 on a six sided die (shooting or melee) and damage on 5-6.

So, for instance, during Adam’s turn he decides to shoot the one of Bill’s units of dinos that isn’t in melee with the mounted unit. He has 6 Lego gunners, and can draw an unobstructed line of sight from one of the gunner figures to one of the target dino figures.  He rolls six dice for the to-hit, and gets two dice at 4 or above.  He rerolls those two dice and rolls one 6, so does one die of damage to the dino unit.  He can either remove one of the figured from the unit, or reduce the general to a one die figure.

Machines, terrain and whatnot

Machines with shooting capability can shoot based on the number of dice they are.  They hit like shooters – 4-5-6 to-hit and 5-6- to damage.  They can only shoot at one unit at a time.  Machines have no melee capability.

Machines without shooting capability are treated like terrain. Shooters can’t shoot through terrain. There is no bonus for cover. Terrain and machines block line-of-sight.


The game is over when one player is left with figures still in the game.  That player is the winner.

Trend Micro now rates backtrack-linux.org as a 'safe site'

I was at a client location recently, and needed to look up some documentation on Backtrack Linux.  For those that aren't familiar, Backtrack is a penetration testing tool, used by security researchers to do a myriad of security tests on website, networks and people. The client uses Trend Micro's Site Safety Center for outgoing requests, and I was suprised and disapointed to find out that Trend had Backtrack's URL listed as 'Dangerous' in the category of 'Hacking'.

Security tools can be used for hacking, just like baseball bats can be used to beat people up. But you don't need a license to buy a baseball bat, and Trend shouldn't be protecting people from tools that could be used for nefarious means. Visual Studio can be a hacking tool; in fact I might argue that it is more powerful and easier to use for hacking in some ways than Backtrack!

However, I clicked the 'This link is miscategorized' link, and filled out the form, explaining that Backtrack is a security tool. I thought that I was just making my case, but nothing would come of it.  Needless to say, I was shocked when I got the following email the next morning:

New Safety Rating
(originally rated as "Dangerous" by Trend Micro)
New Content Type
(originally categorized as "Hacking" by Trend Micro)
Computers / Internet

So there you have it - Trend does listen. I think it is worth keeping companies like Trend apprised of miscategorizations like this. Trying to keep security tools under the wraps of obsecurity 'for our own protection' is a lot like keeping the tricks of lockpicking a secret, and everyone knows how I feel about that!


Pyramath–the first fun math game I’ve seen in years.


I’ve posted about games and education before.  This is about an actual educational game – PyraMath by I See Cards.  This is a small collaboration of educators who designed, developed and produced a series of games for teaching math at the primary education level.  They were nice enough to send Gabrielle and I a copy to use when homeschooling Adam, and we both really like the game.

The premise is simple – starting with a played series of 7 cards, build a pyramid in one of two directions by playing a card that is the sum or difference of the two cards it is sitting on.  If you draw a card you can play, you can draw another card.  Play continues until you cannot play any more, and then you discard the drawn card and play passes to the other player.

The resident kindergartner and I played tonight as part of the evening school I do sometimes to keep in touch with his homeschool efforts.  Gabrielle does 99% of the work, and I like to stay in touch so I do the assessments, have him read to me and play games.


Adam loved the game, and handled the math well.  Because you have to opportunity to play on the six and 9ninecard (for an example pair) until you draw a five or a three, you keep running the arithmetic over in your head.  “nine plus six is 15 and nine minus six is three but I have an eight so not there…” Adam is pretty good at arithmetic, thanks to Bakugan, but this was a very good repetitive resource, with a very visible ‘winning’ position.

If you have a primary schooler and need math drills, put away the flash cards and play PyraMath.  Also look at their other games, FracTazmic, Prime Bomb and I See Cards.  Much thanks to Linda for the demo copy – I’ll be buying more!

The Case for Modeling Part 2

The regular readers of this blog know that my database modeling book was cancelled when Microsoft pulled the rug out from under M and the repository. I did a lot of good writing about modeling in general, so I wanted to put some of it up here on the blog, since the cancellation is official now. This is the second part of Chapter 1.

Why modeling?

Much software is designed on napkins. A story, a mockup, a model is really all that you need to design how a piece of software works.

This book isn’t about user stories or screen mockups. It is about models, and modeling models. It is one part of the trifecta of software design, and it is a very important part.

What is a model? When you say model to my son, he thinks Legos. That’s not far from the truth. A model is the whole of the component parts that make up software. In the example in Chapter one, the model consisted of trucks, boxes, and the relationship between the two.

The further you get into the so called ‘enterprise’ world (meaning really really big software) the more having a consistent model makes it possible to design intelligent software. This is because a good model brings consistent terminology, an abstraction of ideas and an understandable message to the party.

Creation of a consistent terminology

Working on a model makes you decide what to call things in your domain. In the example in Chapter 1, Boxes could be called Containers. They aren’t. They are called Boxes.

Purists will say that it isn’t just the act of deciding what to call things that matters, but instead the decisions that are made. I disagree on matters of principle here. The simple act of deciding to call something a box and not a container is important. Discussion on what a container is matters. Later on, might you have a bucket? Should boxes and buckets both be containers?

This conversation is frustrating but important. This is the selection of nouns in your new language, and nouns matter. They participate in a common language for your business, both in everyday discussion and in software development

Language and software design

They are called programming ‘languages’ for a reason. Spoken languages have nouns and verbs, as do programming languages. The difference is that precision matters a lot more in programming languages, so the ‘dictionary’ of nouns needs to be exactly accurate.

In programming languages, you define your nouns and verbs. Nouns are class instances, and verbs are methods. In a language like Visual Basic, you define the members of the language as you go:

Public Class Box

Public String Destination

End Class

The system has a concept of a box, and the box has a concept of a destination. We didn’t call the box a container, we called it a box. The box has a destination. This is where the box is going. We didn’t call it an endpoint. An endpoint might mean something else.

Verbs work the same way. You might be able to route a box, for instance.

Public Class Box

Public Destination As String

Public Function Route() As Boolean

Return True

End Function

End Class

Now the Box knows a verb – you can route a box. It is an action word – something you can do. We are literally building a new language here – the hip term is a Domain Specific Language, or DSL. It is not a general language. It is specific to our needs.

There is a problem here, though. The Visual Basic code is something that is only used by the developers. Left to their own devices, programmers will come up with the language to describe your business all on their own, and then it won’t be a common language, used by the business and the IT staff.

The key is in a common language

The reason that domain languages are important to modeling is that the software comes out a lot better if both the business users and the software developers use the same words. I probably don’t even have to mention this, because most all of the fine readers of this book have had that conversation:

“But that process only occurs if the router has that one form.”

“Which form?”

“Oh, I don’t know. That one form with the routing information. “

“Which routing information?”

“I’m not sure. It’s a little different every time.”

A common language mitigates this conversation, because they know to say “destination” and not “that information that is needed for the route.” Things have a name. Those names reduce confusion, and cause better software development.

Description of ideas in an abstraction

Creation of a model provides an abstract space to work with the ideas in the system. The architect and the business analyst don’t have to depend on concrete examples with exceptions left and right to design the software, they can work in generalities.

Boxes can be routed, for example. The development team doesn’t have to deal with the fact that Box ABC123 went to Cleveland, and Box DEF456 went to Cincinnati. The exceptions in specific cases are important, and need to be modeled in their own right, but they don’t need to be in the general abstraction that is used to talk about the system in at the 1,000 foot view.

Making models understandable

Abstraction is important when talking to users. To define user stories, the business analyst needs to talk to users all along the process tree. Most users don’t have visibility into the whole process. The receiving guy doesn’t know how Box ABS123 got to Cleveland, but he probably understands that the box was routed. Even if he doesn’t, this idea can be explained, because it is understandable.

Development teams get entrenched in detail. This detail is a necessary as the software gets developed. With an understandable model, though, there is always somewhere to go when you need to return to ‘home base’ and cover the big picture again.

Images versus text

Usually, architects develop diagrams to show models, like Figure 1-4. This is fine, but it gets to be far to complex after the details is added. Few diagrams can be easily searched, organized or simplified. Since we are looking for an abstraction, simplicity is king.

Figure 1-4: A model diagram

An option for a model is to eschew the boxes and use text. Models developed in text can be more easily simplified, and are much more searchable.

Text has a lot of benefits when you are creating an abstraction. First, the viewer doesn’t get tied up by the lines. Often, relationships between items (represented by the lines) are far too complex to make a readable diagram. If you have a simple list of the items that are related, you can just read them rather than tracing them.

The other benefit of using text for the abstraction is that there are fewer blocks to broadening the abstraction. When you realize that the box actually has a relationship with a product, you can just add it, rather than finding the product box on the other side of the page and finding a place for the line.

The conversation between the architect and the developer

The third consideration of creating an abstraction is the conversation amongst the development team members. The problem domain is rarely known when a group of developers get together to solve a particular business problem. Usually a new feature is just that – new – and the terminology being used is foreign to all but the business people directly involved with the process.

Use of a model mitigates this issue by firming up the terminology right from the start. If all of the entities in the business domain are defined and named, the conversation can revolve around the abstraction rather than examples. Even if the business unit itself uses mixed terminology for parts of the business domain, the model will sort out the communication between the architect and the developers.

This conversation is rarely called out, but it a very important conversation indeed. In small and large projects, the big picture is usually in the architects head rather than written down. The architect tries to pass the feature specific information to the developer, shielding them from the big picture. The developer tries to build a focused feature without insight into the overall system. Hilarity ensues.

The construction of a well-understood model provides an abstraction that the architects can use to give the developers context. Context is very important in system development. It doesn’t get in the way of the detailed development work that the programmers are completing, but it does lead to the discovery of contextual errors. Developers can find problems that relate to the system as a whole and apply the fix holistically, rather than just locally in their own feature.

Forming an understandable message

Creating a model allows for communication to be constructed that actually makes sense – especially as it relates to change. In order to communicate to the users and developers about a system, it is necessary to clearly describe the focus points of the system. To clearly describe anything about the system, it is necessary to start with a model.

To some extent, this pales with the need to provide the next guy with a path. Documentation of systems at the design level is notoriously bad. It is never up to date, practically never complete. It is confusing and passes on no knowledge of the business domain. It is useless. Software modeling – done correctly – mitigates this considerably.

Communicating to the user

The user is the person for whom the software is written. It is important that the development team can communicate on a few different levels. First, the user needs to be able to pass on business functionality to the architect. Second, the development team needs to confirm functionality after consuming it into the rest of the system.

During the initial communication about the system, the first thing that needs to be completed is a software model. The entities in the model will provide a base level of communication about the rest of the software. As functionality is discussed, there will be no need to focus on specifics because the model is specifically understood, not just generally assumed.

As important is the review of software designs. When user stories and mockups are reviewed with the user prior to commencing development, there is an understood terminology behind the discussion.

Communicating to the developer

The conversation between the architect and the developer was discussed above, but it bears mention again in this context. Creation of a context for the developer to create features makes a huge difference.

Context isn’t the only issue, however. Users communicate with developers too - especially in agile environments. Testers communicate with developers. Managers talk to everyone. Wouldn’t it be nice if everyone could just use the same terminology? I certainly think so.

The model brings an accurate terminology to the whole team, especially when communicating with the developer. As with the other examples in this section, the terminology reduces errors and the time it takes to communicate ideas.

Communicating to the future

Probably the largest afterthought in system documentation is the next guy. After all, the development staff isn’t being paid to make version two easier, are they? They are being paid to write version one. Nonetheless, having to edit a system is a necessity. Either the technology will move on and the update wizard will come calling, or the business rules will change.

The best way to improve on systems documentation is to remove the problem of updating it on a regular basis. A quality software model will assist with that because it will update as the code is updated. Working from a model removes some of the need for comprehensive documentation.

The business case

It is tough enough to explain to the CIO why you need to upgrade to TFS 2010. Describing just how important it is to totally change the development methodology of the organization even few years is really a problem.

In Software Language Engineering, Anneke Kleppe points out that we need to upgrade our development methodologies now because it’s the shiny new thing, but because we are doing more with less. Dijkstra (1972) called it the Software Crisis, and it is getting worse.

Taming complexity

Year after year, software developers are asked to tackly more complexity. Kleppe describes an environment where it used to be enough to have ‘Hello World’ show up on the screen. With the advent of GUI, consider all of the technologies that have to be mastered to get it on the screen - CSS, windowing, threading perhaps, markup, the list goes on.

What’s more the additional computing power has led to additional expectations of users. Now you are expected to deliver identity and membership, with ‘Hello Mr. Sempf’. Or even delivering more, localization and personalization, with ‘Good evening Mr. Sempf.’

Modeling software tames complexity. Part of the growing complexity of software is that no one person knows the whole system. It is a common story: features need to be added, but the UI guy is on vacation and now there are 24 business rules in the RDBMS.

Accurate models make for understandable software. While nothing makes software easy, not having an accurate model will certainly make it harder to understand.

Enhancing communication

From the project management perspective, nothing makes life better than communication. Weather agile or waterfall, trust and transparency are key. Both of these characteristics require communication. Communication is hard when half of the people at the table calls a container of items a ‘box’ and half of them call it a ‘carton.’

Modeling software enhances communication. Even if all that is done is the simple act of validating the common language it will make talking about the project a lot easier. I hope that you would take it even further than that.

As a project grows, features are added. To build a system of language that assures that the concepts in the application are referred to the same way throughout time. This is essential to good communication, and ease of updating.

With real software modeling, and a metadata implementation, the model follows the software. This means that throughout the lifecycle, the semantics are an intrinsic part of development through the domain specific languages provided in the model.

Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.


profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites