Archive for the ‘Computers’ Category

Sometimes you can spend years trying to find a book that you can recommend to someone who’s asked you a question. My latest read, The Software Craftsman: Professionalism, Pragmatism, Pride is one such book. A recent volume in the Robert C. Martin book series, this volume by Sandro Mancuso is not what it appears to be. And that, is a good thing.

When you look at the other books in the Martin series (Working Effectively with Legacy Code, Agile Estimating and Planning, Clean Code, The Clean Coder, Clean Architecture, …) you see topics decomposed and methodologies expressed by which the title’s subject is achieved. That’s not what you get with The Software Craftsman. In my case, that was a very fortunate turn of events.

This is not to say that the journey of the software craftsman is not discussed. It is and in a reasonable amount of detail. But an equal amount of time is given to the ecosystem within which the craftsman practices. These parts of the book are not for the consumption of the craftsman or aspirant, but for the owners of the firms who employ (or should employ) them.

The book does well in describing the trials and tribulations of a member of the craft; from the point where they realized that they aspired to more than the dichotomy of coder / architect; to the creation of the volume itself. It lays bare this false dichotomy within the broader context of the entire point of software development. That being to produce value to the customer and income to the creator. Within that context, there is the easy path of whatever works and the hard path of building a thing that no only does what it is supposed to, but does it in a way which is both high quality and highly maintainable.

At it’s core, this is book about philosophy. In a landscape of Google and go; and compile it, link it, ship it, debug it; this is a thoughtful volume. It makes the point that I’ve never seen in print, that the individual software developer is responsible for their own career development. Not their manager, not their company, but they themselves are responsible. Heady stuff this.

As to the remainder of the book’s material, it’s more a wake up call to upper management. There you’ll find discussion of recruiting, hiring, retaining, shaping change and showing ROI. I know of very few who could look at this volume and come away unmoved.

It might be the separation of authority and responsibility, the hire for what we needed yesterday, the CYA so we get our bonus, or the factory worker mentality encouraged by so many firms today. If you can read this book and not get something out of it, you’re part of the problem.

Truly quality software is designed, built, and tested by passionate individuals working together toward the creation of something which will well server the customer. Everything else is just code. Any 10 year-old can be taught to write code. I know, I’ve done it. Do you want your life’s critical systems to be build by 10 year-olds? Of course not, that’s a ridiculous question. How about people who are just doing it because they make a better than average day’s wage?

I hope you’re intrigued. At the very least, I hope you’ll reflect on your own views of the responsibilities of a software developer. At fewer than 250 pages, you can read this book in one or two sittings, but reading the book is only the starting point.


Read Full Post »

There’s been a lot of churn lately over the price of Bitcoin. There’s also been much talk about uses (commercial and otherwise) for the blockchain technology that underlies it. I’ve taken an interest, as of late, in the subject and I found a promising source of information in the Michael J Casey, Paul Vigna book The Truth Machine.

If you’re looking for a book on how to write blockchain software. This book isn’t going to be of much interest to you. If you have interest in the history of the technology, its applications and societal impacts, you will find it to be a solid read.

Bitcoin and  Ethereum, and the like are discussed with enough depth to provide non-developers a good sense of use cases. This is after all the point of a technology. Otherwise you’ve got yourself shelfware. All the major players are discussed running the gamut from crypto-anarchists to Wall Street bankers. I find the dynamic of these two extremes battling over this technology fascinating.

One definitely comes away with the sense that the technology is still very much a work in progress. Personally, I find it unfortunate that the public sees it as another get-rich-quick methodology. This loops back to the volatility of the Coin markets.

Another, and arguably more important, takeaway is that the systems currently in place do not scale (or at least have yet to be proven to scale). That Bitcoin can process six transactions per second in a world where Visa processed ten thousand is quite telling.

The underlying problem of who’s in charge comes to mind. Without some form of human governance, poor programming will result in bad actors taking advantage of the system. Nowhere does the book address the issue of longevity. The thing about paper (or animal hide for that matter) is that it has a permanence that has proven itself outside of our advances in storage technology. If we did move to a blockchain-based system of ownership tracking, what happens when another, better one comes along? What will the impact of quantum computing be in a world where work is proportional to CPU expended? What happens when people decide that it’s easier to steal the resources used to mine the coin?

I only have a few issues with the book.

First, for a book on a complex technological subject, I expect extra fact checking. I noticed two rookie mistakes in this department. ASIC is defined as ‘Application-Specific Integrated Chips’ whereas it should be ‘Application-Specific Integrated Circuit.’ It also doesn’t require quotes. In the realm of techno-history, the authors attributed Public-Key Cryptography to Whitfield Diffie and Martin Hellman. This is of course incorrect. That distinction belongs to James H Ellis (at least until the NSA owns up to when they started using it). Although his work was once classified, it have been publicly recognized for some time now.

Second, the book wanders off the path of techno-history and into the realm of  conspiracy theory and political opinion when they introduce ‘speculation’ of hacking in the MH370 incident and spend the bulk of the last chapter on the latter.

On the whole, I found the book to be a very good and current survey of the landscape of blockchain technology and its history.


Read Full Post »

So, you’re the newly minted leader of a group of software developers. Are things really going well or have you merely ‘assumed’ control?

Have You “Assumed” Control

So, you’re now the manager / director / vice president of engineering responsible for a software development team. Are you in control or do you merely assume so? How much do you know about your process, resources, etc.?

It’s 8PM, Do You Know Where Your Source Code Is?

Do you know where your source code is? Without source there is no product. No worries you say, “it’s all in source control.” Cool. Where? Who can access it? Is your IP kept separate from the open source and third party bits you use? Do you have appropriate access control if you have dual company relationships? How much can be accessed by non-developers / contractors? Have your development and IT department worked to establish appropriate backup behaviors to prevent you from capturing third-party source into your corporate backup system in a way that will not withstand an audit? There are mainstream third-party libraries which upon termination of use require removal of all copies. Failure get you an additional year of license payments.

What’s up Doc?

How long would it take to put together a top-to-bottom explanation of any given project in your organization portfolio? Not to have someone explain it all, but simply to arrange a soup-to-nuts set of documents arranged in some kind of self-guided tree that anyone could follow should everyone in the development group be waylaid by aliens. Follow-on, how much critical information is stored only as tribal knowledge, squirreled away in the brains of your staff? How many of your processes require human intervention from a special person to  work at all? Does the documentation you do have match the process you use? Does each piece of documentation have an owner?

The Open Source of Our Disk Content

Do you use open source components? In this day and age, who doesn’t? How long would it take you to inventory your open source use on a per product release basis? Do you have an engineer who works with legal to ensure that the open source you use have licenses that harmonize? Do you have an approval process for using open source? Does you appropriately fulfill the licensing requirements? If you modify the source, do you return it to the author? Do you make the source available on your web site (on a per product / release basis)? On our site, why? In a word “abandonware.” Is this really necessary? Well, there’s open source poisoning. And let’s not forget FSF vs. Cisco. Are your developers using code they found on the web and not worrying because about it because there is no stated license? You do remember that that material is protected under copyright law under the Berne Convention (additional exposition here).

The Very (Threat) Model of a Modern Software General

Does your product ever have interact with anything else? Of course it does. Do you have a threat model for it? At every abstraction level? Do your developers know how to read and create a threat model? A good threat model will help drive your security position papers. Security should be a tangible thing and not simply a warm fuzzy. Make your security staff’s job easier. This also reduces the time required to respond to identified security threats in the wild.

Old Isn’t Gold

There’s a phrase that show up a lot in ads for stock services. You know the one. “Past performance is not a guarantee of future results.” This is absolutely true in software. Whether you’re referring to tools, processes or people, the way things have been done is in no way guaranteed to be best practice, or even supported, in the future. This mirage of stability and security may take the form of build systems without build masters, tool chains no longer available or supported, or any tools that new hires have never heard of. Software development is not a capitalized asset, but rather on ongoing expense. We expect that pens today will serve us well tomorrow, but this is definitely not the case with software tools. Strangely, many companies expect that people will want (and in fact demand) their new software products because of the added functionality. Why would the software tools used to product said software be any different. Additionally, there is the issue of support from the vendor and in some cases the very existence of vendor. It’s akin to acting offended when the doctor you had as a child retires.

Pay no Attention to the Man Behind the Curtain

Do you have projects which are the equivalent of the mystery meat you were served in school for lunch? You know the ones. Old projects or products kept around because there’s one really important customer who still uses it. The kind of projects that rely of AS400‘s or AIX cross-compilers to work. The ones where if one particular individual left the company, you’d end up having to pay them as a contractor just to do the build. This is the hardware / process analog to knowing where your software is. If you have these, they will require special attention and not in a good way.

See No Evil or Monkey See, Monkey Do?

If your software development organization doesn’t believe that there is any reason to review the full offering every two years or never looks outside the organization when setting future directions, you have a big problem. The superstars who brought the organization their last breakthrough are only as good as the last thing they learned. As was heard at GE, “Woe unto ye corporate superstars who have not this day performed a miracle, for you shall be known as bums.” If you never look outside, one day you will discover that you have not been surpassed, you have been rendered irrelevant.

Can’t Touch This

If you’re not organization won’t even consider touching sections of the code base because there might be testing impact (scheduling or resources) or the “you can only change the code if a failure has been identified via some test,” you have severe issues. There are advances in every aspect of computing every day. From the processors, to the compilers,  debuggers, static and dynamic analysis tools, to the very algorithms, someone is working to make the software development process easier, faster, safer, and less fattening. To declare a piece or vast chunk of the code base untouchable says that you don’t understand it and are afraid that merely looking under the hood will loose all kinds of unspeakable horror; or that you hold the belief that the code in question is the realm of genius and mere mortals may not intrude.

Back to the Future

In any sufficiently complex system, there is a not insignificant amount of time between design and production. When instantiated in hardware, the lifetime is further extended. Issue of support will demand that less than state-of-the-art tools be expected and managed. If your product has a lifetime of ten years and you build it with tools, techniques and targets from ten years ago, where do you think you’ll be by the time you end-of-life the product? Where will the people who can work problems be? If you’re lucky your organization will have an Office of the CTO. For those of you who just did a head tilt, the mandate of the CTO’s office to keep abreast of futures. So even if you can’t use the bleeding edge tech today, you can be aligned for when you can. These are people you can go to with the “what if” questions. They provide options and evaluations. Let’s be real, you probably have your product developers working on existing products. You also probably have a very short design phase for new features and products. It’s amazing how many products have suffered from just getting something working and calling it good. Wouldn’t you rather have something better than the top result on Google driving your product design?

Is This the Way to the Vice-President’s Office?

In any healthy organization, you can expect that your developers will want to advance. Do you have a clear, straight-forward and consistently-applied technical career ladder? It should cover both the qualifications, duties and expectations of each rung. Is it up-to-date? Do the engineers understand it? Are there soft aspects? Is it actually used? This is a hearts and minds thing. It speaks to the relationship between staff and management. Some people will reach a particular level and be completely content. Others will want to run the ladder. Having a documented path, gives everyone a basis for conversation and a way to set goals.

On the Bench or On the Beach?

So the organization you’ve assumed has the people, skills and processes to handle all your current needs. You’re golden, right? Now ask yourself how deep your bench is. Do you have an inventory of your teams skills? Is it up-to-date? How fast can you assemble an inventory? Look at it.

Are you tracking the current software industry trends in terms of desired skills, programming languages and tools? Why? Look at your bench. See the rookie end? How do you think they select what they study in school? The smart ones are being guided into the high-demand skill areas by the time they’re in their second year of school. Where is all this drive coming from? The FANG companies. They’re the cool kids. They run at scale. They have the money to explore. They’re the companies you’re competing with for new graduates. Save money and see where they’ve been, what’s worked, what hasn’t and where they’re signalling the future is. Remember, you can tell the pioneers by the arrows in their backs.

Did you notice how the TIOBE and Stack Overflow surveys differ on programming languages? They’re using two different metrics. TIOBE sample commits to open source, Stack Overflow surveys active developers.

Now look at the middle of your bench. It’ll be the biggest section. They’re your bread and butter. Are their skills fresh? This speaks to the career ladder. If you’re using a ladder with out-of-date qualifications and expectations, where does that put you? Do you have mechanisms in place to keep your teams fresh date current?

The veteran end of your bench represent your heavy hitters. These individuals have depth or breadth of experience in domain or technology. If you’re extremely lucky you’ll have a few who have both. There may be a tendency to let them get a pass when it comes to their staying current. Don’t ever give them a pass. With great experience comes great expectations. It’s far too easy to simply trust the word of experience without making sure that they aren’t simply recycling knowledge they gained decades ago. Remember that your organization is competing in a global arena. These are the people who should be spending a large amount of their time exploring both the state-of-the-art and the competitions; and also digesting and disbursing that knowledge within the organization. If you’ve got insular vets setting direction, you’ve got a recipe for failure. Maybe not today, but rest assured, the piper always gets paid. Choice of processor, operating system, development language, communications protocol, user interface all come with cost not only today, but downstream. Finally, are your veterans creating information silos in order to ensure their position or do they make sure that knowledge is spread as far as possible within the organization? The former creates an environment of dependency, the latter spurs innovation. The rookies and mid-career developers must never believe that the views of the veterans are unassailable.

View to a Skill

We’ve explored the experience axis of the bench, but what about the skills axis?

If you speak with your development staff about a new technology / methodology / language and you hear, “that’s cool, but here we …,” it’s time to get those wagons out of the circle. This is sure sign that developers are either unwilling to work on their skills or have been beaten down by management in the past. The former is a one-on-one issue, the latter is a systemic problem.

Back to your skills inventory. Does your organization have the right skill sets to accomplish your mandate? If not, can you get there from here? If you can’t what will you do? If you can, how will you engage and implement? Do you have individuals with skills who aren’t being engaged where they could have a positive impact? It shouldn’t matter their tenure. Do you have team members with skills your teams need? How can you uplift the teams with their knowledge? What if they don’t have skill in the area of teaching others? Your organization should have an active mentoring program in place. If you can mentor one person, you can explain to someone who can train others. Your mentors can be brought into group teaching as domain experts. Your team members with teaching experience already know how to extract information from various sources. To them domain experts are a source capable of answering questions.

The Grass is Always Greener

What is the flow of the development staff? Do developers see sustaining and current projects as a dead end? This may be indicative of the shiny ball syndrome. If developers are climbing over one another to get to the greenfield project is it because there’s the perception that only the shiny and new get resources and the attention of management? Does every greenfield project manifest the same patterns of behavior as the sustaining and current only with newer tools? Are greenfield projects used to reward performers rather than being staffed based on background? When a developer moves to a new project, is sufficient knowledge transfer done to ensure no loss of continuity? This information is particularly indicative of the nature of the organization and is a way that management communicates the value and priority of various projects.

Princely Behavior

Is your organization a minefield of fiefdoms and politics? Allocate half your time to dealing with it. Few things will run your development teams into the ground faster than time lost for engineers trying to please two masters. Many people would like to believe that software development is a democratic process. That’s a very naive view. If that were the case, we’d vote on every decision and everyone would have equal weight to their opinion.

And, Action

Keep in mind the words of Brian Kernighan and P. J. Plauger in their book The Elements of Programming, “Write and test a big program in small pieces.” Make your plan with modest, attainable, measurable goals. It’s no different than creating a software project plan. As you proceed, beware individuals with an all-or-nothing attitude. No large undertaking will cover all the bases regardless of planning. Don’t let the desire for a mythical über-solution stand in the way of a good partial solution. Solve problems in the priority order of the problems, not the perceived importance of individuals or groups.


Image credit: Four Worlds. Creative Commons.

Read Full Post »

I’ve been reading Isaacson’s DaVinci biography (that’s another post) and thinking about metaphors, analogies, teaching and learning.

Teaching is hard. The world is a complex place, so that’s to be expected. Learning is hard, although many people expect it to be easy. I mean, really, like, you can just Google things.

Well, really, not so much.

For me teaching is all about the group and the motivating example. Humans learn best by metaphor, going from the known to the unknown. Kind of like having one foot firmly planted on the lip of the hot tub and testing the temperature with the other. Just jumping in might work. Not something to rely on though. If you give people a framework they can relate to, it affords them a place from which to extend what they know.

On my high school senior physics class final was a problem that began, “A rock explodes into three pieces …”. Really? Why? It’s been a lifetime since that event and yet the premise of the problem still sticks with me. During my undergraduate studies, I had a physics professor whose motivating examples were based on James Bond situations. As contrived as physics problems tend to be in order to tease out a self-contained use of some specialized equation, at least contextualizing thing via James Bond gave them a veneer of reason. Mostly. Sort of.

During my graduate studies, I dropped a class in neural networks because the professor presented the material in such an abstract fashion that I couldn’t anchor it. It wasn’t until I took Andrew Ng’s first Machine Learning class on Coursera (which was one of two first offered) that neural networks actually made sense to me. He presented the material in the context of real-world use cases.

I’m not say that everything can be learned by simply having a good story. If you work with computer software long enough, you’ll have to confront numbers represented in binary, octal or hexadecimal. You’ll just have to memorize the conversions. The same is true for operator precedence.

Let’s look at learning for a minute, lest everyone think that I’ve forgotten it.

In order to learn something, assuming that it’s not rote memorization, you must accept the framework within which it exists. Unless you put can do that, things won’t stick. You will forever be condemned to Google it hell. I can usually tell the people who will have difficulty learning a programming language when they complain that it’s not like the language they’re used to. As I like to say, “you can program C in any language.” Some people never get past that point. And we all suffer because of it.

I’m not limiting this to C-based languages. The interpreted world has more than their fair share of people still programming BASIC in any language. I like to think of them as the Python without classes crowd. I’m not sure where the whole “classes are bad” mentality came from, but it seems to have a strong following.

For a less software example, consider using a word processor. Do you still type two spaces after the period? Unless you’re using a typewriter, all you’re doing is messing up the formatting software (technically hyphenation and justification (H&J) system). Try this experiment. Take a word processing document and look at how it formats the text with both a single and double space. This becomes especially evident when full-justifying paragraphs.

All well and wonderful, but what about the pretzels?

Yeah, about those. I struck me that this whole teaching / learning thing can be likened to making pretzels. You know the big, soft, knotted, salt-covered ones. Consider the dough as the learner, the salt and shape the material to be learned and the kitchen equipment the methodology. The cook is the teacher. If the dough is frozen or dried out, it can’t be shaped. This is a refusal to accept the rules of the material. If the equipment is inadequate or the cook lacks an understanding of how to use it, the results will be inconsistent. Likewise, if the cook doesn’t understand how to handle the dough or when to apply the salt, things will probably not be the best. It is only when all three elements are brought together properly that the expected outcome is achieved consistently.

In the realm of teaching this means that the teacher needs to be able to create a motivating example and framework that works for the learners. This changes over time. Just as the world changes. The teacher should be always looking for signs that a student is frozen and be ready with additional material they may more readily relate to. The most difficult cases are the dried out students. They see no need to learn the new material and are at best taking up air. At worst, they are disruptive. These individuals should be given to understand that their presence is optional and that others should be allowed to learn.

Finally, as a teacher, always, always be looking for what you can learn from the students. The world is bigger than you little pretzel shop.

Read Full Post »

The early years of computing were a like a Renaissance dance, lots of people who somehow manage to get to dance with each other at least once. A Mind at Play: How Claude Shannon Invented the Information Age gives us yet another place to stand and watch that dance.

Claude Shannon is one of those people who fundamentally changed the way we look at the world. The problem with fundamental change is that we tend to be on one side or the other of it. Today we speak of information theory as though it’s as obvious a concept as making paper. Kind of the same way we obsess over software developers being able to write code to sort numbers or reverse linked lists. At some point, the fundamental reality of the existence of high-quality libraries and data structures will make these queries as relevant as requiring people to explain a tape sort. But I digress.

He was a researcher, tinkerer, teacher, juggler, and for all appearances didn’t seem attached to labels. He had Vannevar Bush looking out for him. As an MIT professor, he had Danny Hillis and Ivan Sutherland, among others, as doctoral students. He worked with Alan Turing during World War II. And the box-switch-thing that turns itself off. That was him.

Reading the book, you get a sense of possibilities explored. So often people either dismiss or defer possibilities. He literally had a basement full of them. If only he’d know Ron Popeil, every home might have a few of them.

I don’t know how well he would fare in the world today. In his time, Bell Labs basically paid to have him around. He had cachet. He also helped focus people’s ideas. He brought this sensibility to MIT with him as a professor. We get so terribly wrapped up in being hyper-specialized, in know the what but not the why. To often we come across the proverbial Gordian knot and turn away. People are either unwilling to try, or believing themselves to be special, simply act as though the problem does not exist. (Treating people poorly and flaunting violations of the law fall into this category.) Few people are willing to question the fundamentals. What do you need? What do you have?

The interesting people are those who solve problems and help other people solve problems, not by merely telling them what the answer is, but by enabling them to see that solutions can come from places that aren’t necessarily rooted in the past ways of doing things.

In our day and age, when we focus on special skills and special languages and special hardware, it would behoove us to remember that there is no best skill or language or hardware. There is only the universe of problems. It is far more valuable to be able to help others see the shape of the solution than to be an individual capable of providing a answer to a well-defined question whose value will in time expire.

Read Full Post »

When I was asked to create and teach a Python class, I had to ask myself, “where is the starting point for this language?”

When it comes to computer languages, I like them logical, powerful, compact and fast. The language currently at the top of my list is Swift. When it comes to longevity, C++ wins hands down. Python is neither compact nor fast. It is, however, very popular. It’s also very flexible.

The C language has so many children that it’s easy to use analogs. What about Python?

I’ve taken intro CS courses from Harvard, Rice and Stanford all of which use Python. They all teach C programming in Python in my opinion. I get where they’re coming from. You’ve spent years using FORTRAN then Pascal then Java.

Happily, my first language was FORTRAN. You think you need to build all your own data structures if you use C. Consider yourself lucky. But that’s a story for another day. My second lanugage as APL. Go ahead try to teach APL the way you teach C. Knock yourself out. A bit later I picked up BASIC, which after FORTRAN was trivial. Next came Forth. That took a bit to wrap my procedural head around. My experience with APL had taught me that it’s perfectly fine to focus on the data and not the process. Forth’s focus on the stack is strangely intriguing. The fact that it lives on in UEFI and Postscript is a testament to the fact that there is value in that view of the world.

So my approach was to start with data representation. In Python the world is all objects and references. But for some reason, people don’t want to approach the language from that standpoint. They like to talk about how easy it is to write ‘hello, world’ programs or how it’s more readable than Perl. Aside from APL, I don’t know anything that’s less readable than Perl. Except maybe TECO macros.

Now that I had a place to start, life should be a hop, skip and a jump to classes, yes? Not so fast pilgrim. It’s easy to explain that everything is an object and that integers are a sub-class of rationals. It’s easy to explain that 0 takes 12 bytes of storage. You can even justify the lack of a character object. But I think you do a true disservice if you don’t address the fact that strings are Unicode based. I’ve dealt with enough internationalization issues to know that to gloss over this would be a disservice to the student. I probably spent more time working on the string section of my class than any other.

The reason? It’s one thing to present information that raises obvious questions like, “so you’ve told me that there as multiple ways to represent the same grapheme and that these strings will have different code units, but what am I supposed to do about it?” Or “how am I supposed to sleep knowing that a Vai 4 digit isn’t the same as an Arabic numeral 4?” You might as well throw them under a bus if you honestly believe that you’ve discharged your duty as a teacher by telling the students that there are land mines out there and that they should bring an umbrella. You’ve essentially just given them a compelling reason to never use the language.

Once all the ‘core’ data types are out of the way, it’s time for some core data structure like list, tuple, and namespace.

Functions, generators, and lambdas come next. These are relatively straightforward. The trick to generators is to show the equivalent implementation in C++. Yes, they are different beasts, but you can get close enough. Similarly with lambdas.

Now, you’re in a position where classes can be reasonably explained. A point to mention here is that back before embarking on a exposition of data types, keywords and variable conventions were addressed. Now, for most students, this goes in one ear and out the other. Having arrived at classes, all those naming conventions come back like an overeager Sheltie wanting to play. Ignore them at your peril. Enumerations are also introduced here.

For many, all the object bits will now come into focus. This is a good thing. I’ve never liked the approach where students are taught how to use bits and pieces of libraries without the foundation to understand what’s actually happening. They end up with a false sense of accomplishment and may never seek to build an accurate model of the languages world. They’re like Jeff Goldblum’s character in ‘The Fly’ having no clue how things actually work since he just specified what he wanted a given part to do and plugged the parts together. We all now how that worked out for him. It also emphasizes their importance of debugging you system.

I’ve never understood why some people shy away from classes in Python. They act as though organization is an inherently evil thing. They also probably have all their laundry in two piles in the middle of their bedroom (one dirty, one clean).

Classes point us to resource management, but we can’t do that discussion until input / output is covered. That gives us the idea of using classes (file streams) and their methods to process data. Here’s where string formatting and core data conversion comes in.

Up until now, exceptions have been alluded to. Now there’s enough structure to not only address, but give meaningful examples of their use.

At this point, you’re done with the core language. So we’ll address unit testing. We’ve done bits of this along the way since the introduction of classes, but now we can talk about the unit test library.

What remains are sections on sequence and associative containers. An important aspect of this is teaching how to select the appropriate container. Yes, you can use list and tuple alone, but there are better things to do with your life than reinventing the wheel. Technical interviews insisting that people be able to balance binary trees notwithstanding.

Finally, a brief introduction to the standard library. Before Googling, how about being aware what’s already in the box.

You’ll note a distinct absence of web browsers, GUI applications, client-server systems, etc. Just the language here.

Would my class make you a Python expert. By no means. As with all things, you become proficient through years of study and practice. It is my hope that my Python class would give you a good start on that journey.

Read Full Post »

I’ve just finished reading Code Warriors: NSA’s Codebreakers and the Secret Intelligence War Against the Soviet Union by Stephen Budiansky. It tells the story of the US National Security Agency (NSA) up through the end of the Cold War.

Given the number of dry histories of the people and agencies who deal with cryptography and spying, this book is reasonably readable. If you’re looking for a less arch, and more human view on how things got to where they are; you’ll like this book.

The takeaway from the book is that the biggest hindrance in the world of security is people. People who are control freaks or don’t believe that rules apply to them, or believe that the “other side” is stupid, or are just too damn lazy to do the simple things that would avoid issues are the problem. You can’t design your way around them. If you try, you’ll only make things worse.

You can’t pretend you have the moral high ground when you’re collecting enough information to make the US National Archives, the Library of Congress, Google and Facebook look redundant. I’m not picking sides, I’m just saying that if you’ve got a hammer and you use the hammer, own up to the fact and don’t go around telling everybody and their brother that they shouldn’t use hammers and that in fact that hammers either don’t exist or are illegal (or would be if they did actually exist, which they don’t).

Along the way, you’ll be introduced to a cast of well-intentioned, clueless, brilliant and ruthless individuals. There are miscommunications, denial of responsibilities, bruised egos, moments of insight and face palm moments.

Please keep in mind Hanlon’s razor.


Read Full Post »

Older Posts »

%d bloggers like this: