Thursday, 05 March 2009
A quick glimpse of what you'll find if you search for C++ on the Tech Ed Sessions page:
I'm looking forward to it once again!
Wednesday, 04 March 2009
Here's an interesting post from Rick Segal. Even if you don't want VC money, it's an intruiging exercise to see how you look from that point of view. Let's see how gregcons does:
- Google "Gregory Consulting" and "gregcons". Our site, some sites of other Gregory Consultings in the world (note to self - if I want VC funding, create a sub with a weirdo name with extra vowels or not enough vowels), and some folks linking to blog postings of mine. Not a soul who's actually discussing us as a company. Fine by me but probably an issue if I wanted investors.
- Google "Kate Gregory" and "Brian Gregory". You can see who the public face of this company is - not one of the Brian hits is the right Brian, and all the Kate hits are me speaking, writing, and general experting. Interestingly Google (which I never use for my own searches but am using in the spirit of Rick's blog) doesn't find the "other" Kate Gregorys that Live tends to return. I'm not actually the only one on the planet.
- The mission statement. Um. Well, we have a tag line on the website "Leading your developers forward" so I'll give that a try. Interesting way to discover who is mirroring your old content chrome and all, but you don't learn much about us from it.
I think we pass the test of being discoverable on the internet, but it's clear people don't talk about us as a company much (they do talk about me from time to time). Fun exercise. Try it yourself!
Tuesday, 03 March 2009
I've been accumulating some links that might be relevant to folks looking for work. I got a lot of traffic to a post last year about trick questions in a job interview, so I thought I'd share these as well.
These posts are very different, but they all have useful information for you.
Monday, 02 March 2009
Programmers make mistakes, we all know that. But some are worse than others. Say you hardcode a file name, and you make a typo in the name. When you do your own testing before passing it off to others, you'll discover the typo because it keeps the application from working. But if you fix the typo, there's a good chance no-one will notice the other mistake - hardcoding the file name - for a very long time. In fact, if the file never moves, under some circumstances you could claim it isn't even a mistake to hardcode the name. But if the file does move, hardcoding the name is a much worse mistake because it causes a bug that a customer discovers - and that is always bad. Writing your data access code so it brings back the wrong records (say, forgetting to filter by date) will show up the minute you hit F5, but writing your data access code so it's vulnerable to SQL injection is far worse - you'll think the application works, but when you put it into production you'll have opened a large hole into your database for bad guys.
The SANS Institute has created a list of what they consider to be the 25 most important programming errors of all time. There's a lot not to like in this list, to be honest. First, it's not so much a list of errors (John typed this line of code in that application) as it is kinds or categories of errors. Second, a lot of them look like the same error over and over (trusting stuff that people give you as input, for example). Third, the post spends pages and pages on credits, acknowledgements, explaining why they are important, predicting how the world will be made better by this list existing, and so on before finally getting to the errors. Fourth, the names are flat-out weird in a lot of cases. But with those disclaimers in mind, I still think the post is worth reading and the errors are worth thinking about. Here are the 25:
- Improper Input Validation
- Improper Encoding or Escaping of Output
- Failure to Preserve SQL Query Structure (aka 'SQL Injection')
- Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
- Failure to Preserve OS Command Structure (aka 'OS Command Injection')
- Cleartext Transmission of Sensitive Information
- Cross-Site Request Forgery (CSRF)
- Race Condition
- Error Message Information Leak
- Failure to Constrain Operations within the Bounds of a Memory Buffer
- External Control of Critical State Data
- External Control of File Name or Path
- Untrusted Search Path
- Failure to Control Generation of Code (aka 'Code Injection')
- Download of Code Without Integrity Check
- Improper Resource Shutdown or Release
- Improper Initialization
- Incorrect Calculation
- Improper Access Control (Authorization)
- Use of a Broken or Risky Cryptographic Algorithm
- Hard-Coded Password
- Insecure Permission Assignment for Critical Resource
- Use of Insufficiently Random Values
- Execution with Unnecessary Privileges
- Client-Side Enforcement of Server-Side Security
The full details are in the linked post and it won't take more than a few minutes to read the description of each error. Pat yourself on the back, or go do a quick code review so you can say you don't do any of these.
Sunday, 01 March 2009
Being a Microsoft Regional Director has a host of benefits, most of which are intangible and hard to explain to someone who's not experiencing them. The number one benefit, for example, is the other RDs. They're such a smart and fun group, and the connections have helped me personally and professionally. The only drawback to being an RD is that so few people know what it means. They think perhaps we work for Microsoft (nope) or that it's like being an MVP (nope, though many of us are MVPs as well) or that we get paid to do it (nope again.)
Recently Joel Oleson had a crack at it. The phrase "unbiased evangelist" is a little tricky, isn't it? And we're not exactly evangelists either ... Microsoft already has people for that. I would say that we've chosen Microsoft technologies (not always exclusively) for our own reasons (that is, not because someone compensated us directly for choosing them) and we're happy to share our reasoning with others. It's that sharing that gets us the nod to become RDs.
Saturday, 28 February 2009
I've been doing some training lately and of course conference season is on the way, so I'm starting to think once again about the mechanics of talking to audiences. One relatively recent change in audience is the popularity of Twitter. It is starting to create a far more public backchannel, one that even the presenter (or the presenter's colleagues) can read and respond to during the talk.
Private, even secret, backchannels are nothing new. I've been on many a conference call where 5 or 6 of us are on Messenger discussing the call itself (and we probably wouldn't want the speaker to read what we were typing.) I've also been in physical meetings where a small group of people are privately discussing the meeting itself, whether co-ordinating who will say what when, or just aimless snarking and wondering when we can leave.
But a public backchannel, maybe even one you have an obligation to monitor, is a very different beast. Some folks, like Olivia Mitchell on Tamar Weinberg's blog, think it's all-good all-round: better for the audience, the presenter, the world as a whole. Presenters just have to learn new reflexes: when your audience suddenly starts typing and looking at their screens, it doesn't mean you've lost them, just that you're so interesting and the information is so important that they feel the need to share with the world immediately. Ira Basen is not so sure, especially if the tweets are negative and going out in public before the talk has even finished and without asking the presenter any questions.
Different conferences will probably lead to different conventions and habits. I can imagine a lot of tweeting from a keynote where things are being announced or demo'd for the first time. But if I'm doing an hour on C++ 0x features, I can't really see why "OMG Lambdas r AWESOME" can't wait until the talk is over. "Now showing capturing the whole stack by reference" doesn't seem like a likely tweet. I can tell you that I'm not going to have a window open on my screen where I'm following "my channel" and that if you want to ask me a question, it's going to involve speaking aloud, at least for now. That said, it's a good idea to think about the impact of wireless internet in every room and instantly-constructed channels on speaking, on conferences, and on the way we all share information. I think there will be more room-switching early in talks if people learn that someone else is really doing a great job, and attendees may demand more agility in scheduling repeats and extra sessions on topics that were well received. As always, we live in interesting times.
Friday, 27 February 2009
Ronan Geraghty has an interesting blog, full of topics that interest me, with lots of BizSpark, WPF, Windows 7 and client development content. In a recent entry he explains that getting the Windows Logo on your software product is going to be a lot easier for Windows 7. Instead of submitting your application to a third party for testing, you can test it yourself and get certification without paying someone else.
Why would you want to certify your product and get the Windows Logo? I can think of at least three reasons:
- The certification process may raise your quality bar by imposing some constraints on you that you were planning to skip.
(Have a clean, reversible installation; Install to the correct folders by default; Support Multi-user sessions; etc.) That may feel like a drawback to some, but for those who wanted to put these features in, the logo program may be a good reason to have them.
- There may be some customers somewhere who are more likely to buy something with the logo on it. There certainly are none who are LESS likely to buy because you took the time to get certified.
- Having a logo'd product gets you a competency in the Partner Program and makes you a Certified Partner, which comes with a suite of benefits you're sure to want.
So making it easier to get the logo is nothing but good news. Follow Ronan's links for more details.
Thursday, 26 February 2009
Michael Feathers put together a list of ten papers that "every programmer should read". I've seen such lists before, and this one is pretty good. I've read Parnas and Cunningham and draw on that background pretty regularly. I'd heard of some of the rest. But the real fun begins in the comments. People suggest additions (Fred Brooks - definitely! Joel Spolsky - why not?) and then other people start saying that reading, especially reading stuff from 20 years ago, just makes you an academic and not useful. Oh my.
I'm useful. I've written a lot of code that's made people's jobs and working lives a lot easier. I've written systems that have transformed companies and enabled them to survive business model changes they thought would sink them. I've rescued projects and made developers better than they were time and time again. And I'm academic. I have a Ph. D. for heavens sake, I teach at a university (no, not full time, one course a year), and when someone uses the word "academic" or "intellectual" as an insult, and I object, they tell me "you're not that kind of academic, not the kind I meant." Well honey, to paraphrase Gloria Steinem, this is what academic looks like. Reading 20 year old white papers and thinking about concepts and theory is one of the things that makes me useful. Folks who just want to get started and type some code and not bother with that high falutin design stuff tend to write bad code.
Grrr. Read the list, maybe read a few of the papers (as the commenters mention, Michael's links are to a site that will charge you to read them, but if you have the author and the title your favourite search engine will undoubtedly help you find free copies lying around on the web) and think a little about why it would be an insult to say that someone cares about history and theory.
© Copyright 2017 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Saturday, 16 December 2017 11:53:01 (Eastern Standard Time, UTC-05:00)
On this page....
Pluralsight Free Trial
Click Subscribe, then Start 10-Day trial