Actually the process was not terribly difficult. The auto-refactoring capabilities of VS2005 do much of the grunt work of altering references for you. So once you select the appropriate type from System.Collections.Generic, it's pretty elementary to feed it the type you want the Collection to be. In my case, the List type was sufficient (as I didn't really need a typed key, or sorting capabilities, or some of the more elaborate functionality available in other members).
The one thing that did trip me up at first was that I needed to verify whether elements already existed within my collections prior to adding them--which is what I was trying (unsuccessfully) to do with ArrayList.Contains(). But, again, Brian came to the rescue and this was pretty easily resolved. The collection element classes I was working with needed IComparer<> classes to go with them. The IComparer<> interface is very easy to implement, primarily consisting of the Compare( x, y) method. In implementing this method, there are some basic rules that allow you to sort out the process of actually comparing the two objects. But in my particular case, the extent of comparison possibly was greater than what I needed, since I really only cared if the element being passed in already existed in the collection. So my implementation was extremely simple.
Once the IComparer<>.Compare() implementations were defined for my collection element types, the matter remained of determining which method of the List<> type would perform the task at hand. As I mentioned, the reference comparison done by ArrayList.Contains() wasn't doing it for me. At Brian's suggestion, I used the BinarySearch() method of the List<> type. It allowed me to pass in the element I was looking for, and used my IComparer<> implementation to return 0 if not found. A non-zero return value indicated that it was already there. As a sidebar, my implementation of the Compare() method could have told me more about a found element's relative value, but as noted this was not really important in this context...
Anyway, the somewhat goofy side of this exercise was the limited way in which my app legitimately benefited from using Generics. The number of collection elements in this app is going to remain relatively small--certainly not getting into the territory where the speed boost yielded by using Generics would impact performance. However, using Generics did allow for more elegant code, as several "for" loop constructs gave way to slicker "foreach" statements, and I was happier in general with the explicit type-safety of the Generic collections.
]]>All the docs required for my previous corporate gig were pretty much for a technical audience only, consisting of a requirements overview and quasi-detailed functional specifications. Neither of these was ever examined (or, in many cases, read at all) by the business team. The information they wanted was communicated in emails, meetings, and by "unofficial" throw-away docs printed specifically for said meetings. I was also the coder in almost every case, which rendered the functional specs doc somewhat superfluous or at least redundant for development purposes. But even on those, my personal investment disallowed me from permitting spelling/punctuation/gross grammatical errors, and my conscience as a developer kept me from throwing in "filler" or just skating by with them. Plus, those docs were used by QA to establish a test plan, so there was an actual purpose and audience.
So what's the difference between our two coexisting worlds? Well, it's not so predictably cut and dried in this arena.
In the consulting world, your document deliverables had better be A) actually "deliverable" and B) worth doing. If you're burning hours on something of no value to client or company, or, worse yet, that makes the company look sloppy or incompetent, then why bother? Depending on how formal the shop is regarding methodologies, I'd wager that you will typically have a "leaner" set of documents on the average project in a consulting shop. You will do what's been contracted or is necessary for client communication, but no more. The rest of that time MUST be spent on actual development, creating the product.
In the corporate world, the documentation experience runs the gamut. Some places have actual document templates (with varying levels thought put into them, yielding various levels of success), while others work it freestyle. Some places actually have active audiences for their development docs, others not so much. Some shops go way overboard on requiring deliverables, others undershoot healthy levels of documentation. In my corporate experience, the required documents mostly had value, but were frequently unread by their target audience. However, I've also been witness to the birth of vast numbers of RUP artifacts into a corporate project atmosphere of total apathy. Sheafs of use-case diagrams, sequence diagrams, UML versions of the Last Supper -- you name it; unread, unused, sent straight to dead-document heaven. All just to satisfy a decree that RUP should be followed TO THE LETTER. So documentation in corporate development is harder to singly classify. There is plenty of room for and evidence of the waste I typically attribute to the corporate world. But there are also sensible examples.
]]>Still, one area of rough sailing has been moving from a medium-to-large corporate to a small-to-medium consulting environment.
In the corporate world, the daily "speed of life" slows to nearly minus-infinity. Exceptions exist, but most corporate IT departments just seem to drift along with the current. Executive decisions arrive with astounding glaciality (note: not a real word), and response to those decisions is executed at half that speed. Over schedule? Over budget? Big deal. Other departments/branches/divisions carry us when we're off. "We're paying for you, so we better keep you nominally busy into the next decade" seems to be a prevailing attitude. As a result, it's easy to get lazy, rely on heavy estimate-padding, push development a little into planned QA time. Of course some people must always jockey for political position, which complicates things a hundred-fold. And in general, career growth pressure is actually negative. I remember reading Donna D. describe in a previous post that I can't find right now the piss-poor (my words, not hers) attitude some workers develop about picking up new skills on their own.
But in the consulting world, the focus on billable hours drives it the other direction. You NEED to get massive quantities of work done, but time is a scarce commodity, as is one's focus. You are split between projects, requiring you not only to budget yourself carefully but to max out your mental abilities keeping things straight between them all. Deadlines mean more because missing them means money directly out of the bottom-line. Reduced size = reduced politics = reduced focus on unimportant junk. A more team-oriented mentality pervades. And you get career growth simply by virtue of the fact that every client needs something a little different; there's always a new 3rd party interface or library to learn.
At least, this is my experience. Can you tell which I prefer? :?)
More on this later. Right now, I've got documents to edit...
]]>At first, I thought I could express it all in this comment on the article which I made in response to a comment from Mario Van Damme. But I realized after I posted it that I had more to say on the topic. This whole issue hits home for me because I have lost out on at least 4-5 job opportunities due to the prospective employer's determination that I was short on business domain knowledge. Now, I'm well over missing out on job opportunities from years past, so it's not a personal thing. It's definitely a professional thing. As I mentioned in the comment linked above, there's something here that just does not compute (pardon the pun).
The literature of the field, the formal education available, my own experiences and those shared with my colleagues and peers -- it all points to this line of thinking being totally invalid and actually contrary to the reality of software development as a profession. It's not only incorrect, but potentially harmful.
Here are some points of evidence:
The key here is that there is both a separation of concerns and a marriage of two kinds of expertise. Developers are experts at building software, creating solutions that in and of themselves are stable, robust and account for big-picture concerns at the IT infrastructure level. They know the technology and the architectural techniques for creating the software. Subject matter experts--be they accountants, medical office managers, salespeople, retail clerks, what have you--are the vital and critical other half of the equation. They know the specific rules that the developer must encode into the solution to make it applicable to the problem.
Does a pharmaceutical rep know the exact molecular biology involved in the actions of the drug they peddle? No. A chemical engineer and/or a molecular biologist and perhaps a team of physicians worked on that end. The rep sells it. They know enough to speak intelligently, and they know the limits of their subject area knowledge, and they know mostly about sales techniques. Done.
Why do lawyers retain expert witnesses? Why does a general practitioner refer you to a specialist? Do you see a pattern here?
The bullet point in Sarah's column about "Minimizing Risks" is where this connects. Something she implies there, even if it isn't stated outright, is that the professional developer is, in general, responsible for abstracting the solution away from the problem. This is how risk is minimized; the design of the solution should provide flexibility along the lines of business logic, such that requirements changes are not catastrophic -- even late ones. The structure of the solution, at the code level, should be implemented such that testing, deployment, and ongoing maintenance are not disasters waiting to happen.
What the developer is not, and should not be, responsible for is knowing the ins and outs of the problem space going into the project.
As I mentioned in my comment to Sarah's article, there needs to be an organic absorption or osmosis of problem space/domain knowledge that the developer undergoes during the lifetime of the project. Active resistance to that process is problematic. But to disqualify a developer from a project/job due to lack of previous experience with a given problem domain... That actually undercuts the entire profession with a logical move completely counter to the purpose of hiring the developer in the first place.
Rant ends. Good day!
]]>Lots of personal stuff has been going on, which I'm somewhat loathe to discuss in this context as it's just so OT w/r/t Dev Dot Star stuff, but suffice it to say it's all been positive financially, mentally, and musically.
What's more germaine and exciting is the fact that I have finally left Business-X in the dirty past, and moved on to pastures new and, thus far, apparently greener. Thrilled to be in my new gig, and excited to get down to business as I move past the "orientation and desktop setup" phase of things. It looks like I'll be doing some WinForms coding in .NET 2.0, which is extremely satisfactory compared to my last set of assignments.
I should note, esp. to anyone who is at all familiar with just how much I disliked my previous job, that I was able to FULLY express my dissatisfaction to B-X when I left -- in several exit interviews/meetings and in my resignation letter. This was done without pulling punches, but also (I hope) without losing any professional grace or dignity. The place had problems, and I felt it professional responsibility to alert them. Beyond that, it's their grave to dig....
And finally, I will also mention that I passed (nay, "whooped up on") MS Cert Exam 70-315 with a score of 943-1000. I was pretty happy about that. Note my earlier post about exam prep materials if you have any plans to take this test.
More to come soon...
]]>To begin with, I should say that Bach is and always has been my main man, my fave composer, the baddest of the Baroque. YMMV, of course, but I have the utmost respect for him as both a musician and a programmer for his mastery of both counterpoint and symmetry.
I realize I'm already in danger of veering wildly OT here on the DDS, so I'll try to cut right to the chase and describe how this is related to software (I'm going to have to take for granted that the reader knows or will look up the terms)...
Both of these elements of music, to my mind, have stylistic counterparts in programming, and they are both related to each other. Listening to one of Bach's more concise pieces--i.e. selections from the Well-Tempered Clavier, several of the Two and Three-Part Inventions--impresses me the same way as does looking at a well-architected software system.
There is frequently an element of "wheels-within-wheels", an almost fractal quality that permeates the structure. Elements at low levels of detail echo or mimic elements at high levels, and vice versa; a given method has a striking resemblance to the class of which it is a member. You can virtually--and sometimes actually--see the thinking of the programmer as it is molded into the code itself.
A similar idea is the writing technique of paralellism, where repeated syntactical structure lends additional semantic meaning. But that might be tangential to my point. Uh-oh.
I think I'm going to bail out on this before I dig myself in any further. I'll leave the reader to dig up a copy of Hofstadter's Godel, Escher, Bach to prove I'm not completely off my rocker...
Regardless, good code exhibits the best of what made Bach's music last some 300+ years so far. I want every piece of code I write to emulate that quality.
]]>For you unfortunates who haven't had the intense physical/psychological pleasure of Microsoft certification, exam 70-315's topic is "Developing and Implementing Web Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET".
Surely you'll allow me the numbers on this one going forward.
The 70-315 is pretty much all about ASP.NET in C#. There's also some stuff about VS.NET, a little bit about Web Services (they really go deep on that on the 70-320 exam, my next target), some build/deploy stuff, etc. This exam is my first step towards upgrading my existing MCSD cert to and MCAD and quasi-current status. Quasi-current because as of the beginning of 2006, MS has completely changed their cert structure, titles, exams, etc. I have little, if any, temptation to charge off down that path at this time. I have my bread well-buttered in the existing (and still valid, mind you) cert structure.
Because of how I took the exams for my old-track MCSD, I only need to take two exams to pick up the MCAD cert. That puts me as certified in .NET, but without having to essentially start from scratch and take 4-6 new exams to get there. Not a bad trick. It's a move I learned in college -- the "prerequisite pivot". You should've seen the wacky stuff I took to fill out my entire core curriculum in the space of, like, 3 classes.
But so it's been an interesting course studying and prepping for this test. First, I grabbed the QUE book on the subject by Amit Kalani. I can recommend that pretty highly. Kalani knows what he's talking about and presents the material in a way that's helpful for exam prep. I actually went ahead and grabbed his 70-320 book when I saw it on clearance. But I could tell that a book alone was not going to cut it.
For every other MS Cert exam I've taken thus far, I've used Transcenders to prepare. They always skewed significantly more difficult than the real thing, plus the actual practice test mechanism closely resembles the real thing, and the modality they provide for taking practice exams, finding your weak areas, and concentrating your study were invaluable. But I was advised that Transcender was not as hot on the newer exams, specifically the MCAD/new-track MCSD exams. The material they had wasn't as up-to-date, the question formats had changed, etc. I hate it when that happens.
I was instead advised by a trusted... um... advisor (how do I always do that?) to use TestKing stuff instead, because they essentially composed their practice materials from actual exam questions. It was certainly cheaper (by about half the cost, actually). But I was instantly less than enthralled with what I got.
TestKing gives you a copy-protected 200-page PDF which they encourage you to handle with Acrobat Reader 7.0. OK, fine. I guess. Commence upgrade and 3rd party security plug-in install. Done. Unpack and open the PDF, hooray.
Then I go to print out the beast in a portable format (2pp/sheet front and back, to compress 4pp onto one piece of tree skin -- save a tree or 10, you know), and lo and behold (!) nothing happens.
Investigation provides this nugget: Acrobat Reader 7.0, says TestKing (at the very end of the TK troubleshooting document -- and nowhere else) has "known printing issues". Their advice? Downgrade to Acrobat 6.0 or below. Thanks, guys. Heaps. The upshot was, about 2 hours later, I still had to destroy most of the rainforests of Laos and Ecuador to print the damn thing out. And as far as portability goes, have you tried carrying around half a ream of loose sheets of paper lately? Fun with binder clips.
But the thing is, yes, the materials TestKing provides are very clearly ganked directly from MS' exams, with only the phony-baloney company names in the questions changed. And many, many typos added. But if you've taken one of those exams you can smell their questions a mile away, and these smell real. So the quality of the material is there. But ultimately, I REALLY REALLY REALLY prefer doing the Transcender practice tests to studying from a paper document. I could take 3 (or more) practice tests in sequence, printing out all the questions (with detailed answers and explanations) that I missed each time. I could study those, take the next practice test, and watch my score go up each time. After the third practice exam, I would be pretty much completely prepared for the real deal. I scored an average of 200 points higher on the real exams than on the Transcender.
So this exam will be something of a crucible. My continued use of TestKing stuff is certainly on the line. If their material is as close to the exam as purported, I will probably get their kit for the 70-320 as well. But if it isn't pretty much on the money, I will very likely go back to paying a bit more for the Transcenders. It such a better fit for the way I want to study that even some inaccuracy would be worth it.
]]>He spoke primarily about safely aborting Threads in .NET 2.0, and went into some fairly intricate detail about how it's done at the code level, and about changes in 2.0 that can make mutli-threading significantly safer with respect to use of unmanaged resourced.
I won't go into tremendous detail (for risk of misquoting or otherwise mangling the information) other than to note that I was surprised at how technically "unsafe" certain very common aspects of managed code use were under .NET Framework 1.0 and 1.1. Particularly, any kind of Interop activity in a multi-threaded environment has some potential resource leaks and even security holes. Luckily, much work has been done in v2.0 (largely at the behest of the SQLServer team, who are understandably interested in NOT having either resource leaks or security holes) to remedy the situations.
I'll provide a link to Jeffrey's slide deck when it's posted online.
Yes, I would indeed like fries with that.
It marks two full years of daily unlearning all that which I had spent the previous five learning, like an obedient dog smacked across the snout with the rolled-up newspaper it had just carried in from the curb. "No, master.... no, master -- Igor will remember to only make the code, master.... master's way is the best, I cannot hope to improve on the master's genius...."
Funny how much my thoughts on job longevity have changed in that time. When I took this gig, I was thinking that what I really needed was to supplement the project-based short-term work on my resume, to stay somewhere for several years and grow in a position, in both technical and "soft" skills.
And now I say "HAH!" Yes, that's right: "HAH!" Not only were my assumptions wrong, the path I took was compeletely heading the wrong way!
I can honestly say, though, that I have grown--inasmuch as I've come to realize that I function much better and serve both employers and customers better as a contractor. Further, my own personal well-being, I've learned, is actually threatened by staying at a dev gig for too long. It breeds laziness, false contentment, myopia, fear of change, gout, scurvy, black hairy tongue, scoliosis, recidivism, mutually assured destruction, technological ghettoism, halitosis, unusual spots, cramping, bloating, water retention, and an extraordinary need to imbibe/self-inebriate. Heavily.
And something else I've determined (to my surprise) is that I do not, as I had previously thought, hate the business software space. Rather, I strongly dislike certain aspects of business in general that are altogether common, but not totally pervasive. To be more specific I find that, in classic geek style, it is the businesspeople I have the most trouble with.
So, my next trick must be to find a place where those aspects/humans are at least kept to a bare minimum. Somewhere I can provide maximum value to an employer without making myself go absolutely bat-shit crazy in the bargain. A situation where technical expertise is required and wanted, not only in name, but in deed.
Clearly that's asking for too much. But baby (or babies) need(s) a new pair of shows (every 6-8 weeks), so I gots to get me a paycheck.
And now, as my odyssey of professional self-discovery continues on this negative-learning road here at B-X, I close this post hoping soon to be able to look back on my slightly-more-than-two-years here, and shudder only briefly.
BTW - I have an interview tomorrow. Wish me luck... ;?)
]]>Well, maybe it's not so much a mystery. More of a buzzword, and one I was growing sorely tired of reading-but-not-knowing. Until this morning, that is, when I dove into the deep end of blogosphere (talk about buzzwords) and tracked down the definition of this AJAX stuff. Courtesy of a link on Keith Rome's blog, I was able to dig into 5-8 sites, every single one of which failed to provide a simple definition of the term, so caught up were they in the buzzword feeding frenzy.
*** By the way, I love it when a website is so dedicated to something that it totally fails to provide even the most basic topic-sentence information in favor of balls-to-the-wall, in-depth, geek-centric coverage. C'mon guys, a 4-question FAQ page or a link to wikipedia isn't that hard to muster... ***
So imagine my surprise when I discovered, after finally finding such a link (hit it above), that AJAX is the same damn thing I've been doing for years now. Apparently, it's been given a snazzy new name by some bloggers somewhere, which caught on, and now they're giving presentations at some geek conference somewhere for several thou per engagement, including expensed airfare, hotels, and meals, wiFi hookups, digital cameras, fruit-bats, breakfast cereals, etc.
And so it came to pass that I learned something nice about AJAX--that I was actually AHEAD of the curve on this particular buzzword. I was doing Remote Scripting in ASP 6 years ago, followed XmlHttpRequest techniques across both M$ and Java technologies, and looked at ASP.NET callbacks and said "well, DUH".
I guess my curmudgeony attitude about this comes from that same place--"Well, DUH". Of COURSE it should be a primary goal in ANY type of development to emphasize and maximize the user experience. You should always have that top-of-mind as a modern software developer. The mixing in of whiz-bang technology notwithstanding, you should plan your design and architecture around the user's needs as much as possible. Is that really a revolutionary idea? If so, it would seem that the inmates truly ARE running the asylum.
And concerning the whiz-bang stuff, it's important to keep in mind that sometimes it's neither appropriate or the best solution. This can be for architectural reasons, because of the target audience for a given web app, because it adds complexity to an otherwise simple solution. Plus (and I say this from experience) you can screw stuff up with respect to maintenance and testing by doing too much tricky client-side coding. It's hard to debug, race conditions can pop up faster than you can load that IFRAME, XML is not a silver bullet, DHTML/XHTML is not even really applicable on older browsers (yes, Virginia, there really are still Netscape 4.0 users), etc.
The product I currently spend my days with is a good example of the fact that these techniques have been around for a good long time. We use LOTS of javascript and XmlHttpRequests, in addition to RPCs, in order to create a web-based user experience that is very c/s-like. Of course, this is also an example of the caveats I mention. The app is buggy, hard to maintain, loaded w/ complicated JScript and standard ASP 3.0 spaghetti code, and is sometimes a dog because of almost constant walking of DOM trees. A healthy dose of XSLT would actually cure a lot of that, but as I have indicated in my previous posts that sort of change is not at the top of the list of Things-To-Do here at Business-X.
All that said, "AJAX" is cool stuff, and it's really the way to go barring the presence of the concerns I outline above. It feels nice to be beyond the bleeding edge for once! I look forward to digging into some newer flavors of these techniques, using Ruby on Rails, Python, etc.
]]>It's all in a day's work, here at Business X: Home of the WHOPR (a little WarGames joke, for the kids). Actually, we don't have a WHOPR or anything like that, all vintage and AI-looking. That would be cool.... but only our codebase is "vintage". If you can call 1998 vintage, which you can't.
Nor is it a day's work, given that our release cycle is more like 2 months. But it sounded like a fun name, and I got to write "all in a day's work". But as usual, I digress...
The point isn't the errors resulting from the release--the team is good enough to have all those handled before any sort of customer exposure or backlash could come into the picture. The point, instead, is that it pains me greatly that any release errors should happen at all, and that the level of manual effort required to perform a release remains pretty constant after leveling off last year.
See, I'm the guy who inherited the job of "InstallShield Chump" here at B-X. I got it because the person who used to do it had amassed enough political capital (thanks to W for that phrase, which I looooovvve to overuse) to legitimately complain about it, and even to be acknowledged and listened to. Whoa. So, since I was the last person to squawk about how bloody awful our release process was, I pulled the duty without meaning to and definitely without wanting to. Therefore: I, InstallShield Chump.
And when I say "squawk[ed] about the release process," it should be clarified that "squawking" merely means providing my solicited opinions/observations about sitting here in my cube for 12 hours on a Saturday to help perform a task that should be largely automated to begin with. This happened less than 2 months after I joined the team here at B-X, when I was eager to bring my outside experience to bear on whatever problems I encountered. Well, you should have witnessed the flaming hatred of our config manager when I expressed how ridiculous a waste of person-hours I thought our release process was. You'd have thought I recommended keying her car twice daily until things improved. And so it came to pass I was tasked with improving the process, and so it was thusly improved. The longest anybody has spent here for any subsequent release is roughly half that time, and that was due to a server failure during the release itself. But then, after making the improvements, I became the I.S.C. For improving the process my reward was to be permanently shackled to it.
Still, even with my magic handcuffs, I'm pretty powerless to make the changes that need to be made. Part of it is the sheer number of moving parts in our system and the oddball architecture under which they're deployed. Part of it is organizational sluggardry and political geechiness (yes, I totally made those words up. I have a cold). But in our "post-mortem" meeting this morning I actually heard myself pointing out, in so many words, that tilting at this windmill has been done, that significant effort had been made but that a brick wall had been hit in terms of process improvement on our (the Dev team's) end.
So apparently, I've drunk the kool-aid without even knowing it. Or maybe I'm just learning to put my effort where it counts, and not hurtle headlong into that same old brick wall.
Or maybe it's just the cold talking...
Sincerely,
Your Working Boy
Interesting results.... or maybe not. I could have told you there was very little class on the internet.... (heh heh heh)
]]>As further background for my decision to make a focal point of Agile methods, I should point out that virtually every single experience I've had in my career thus far has led me to the conclusion that, for the vast majority of business software, some flavor of iterative development methodology is the way to go. Any time I get involved in a position where someone is clamoring for a heavyweight up-front requirements period, or for extensive documentation, or where people immediately start in with "it's not time to talk about code yet," my spider-sense goes off like an H-Bomb. I'll almost certainly return to this point again and again, as I think it's something I've already discussed in the few posts I've made previously.
Anyway, I should note that this book is part of the Addison-Wesley Agile methods series, edited by Hightower and Cockburn--a series which I've heard great things about edited by two professionals whom I respect a good deal. I'm about halfway through already as it's a very quick and easy read, just a summary of the title topic from the 10,000-ft view aimed at newbies and managers. I'm not really either of those things, but when I looked through the book I saw it as a great source of ammunition and ideal info to have on tap for non-believing managers and curmudgeony types with their methodology still stuck at "GOTO considered harmful."
Thus far it's proved a good purchase decision. Larman's a very readable author, and this book does an admirable job of summarizing why waterfall, in general, sucks. Although there's a high possibility that it won't remain on my shelf due to it's generality, it will almost certainly remain on my recommendations list--especially for managers.
]]>Still, with the New Year I've been taking stock of my priorities and I've determined that I really should make a legitimate go of keeping up with my blog. So I'm making that one of my very few resolutions this year. And here we are, which brings me to my next resolution...
I need to strongly re-focus my energy towards "outside learning". Up until last year, I had always made a concerted effort at keeping up with industry trends, both techological and business-oriented. I devoured several trade rags a month, worked through two or more software development books at a time, attended seminars and user group meetings. But I've been sucked in by that most dangerous of forces: career inertia.
I've grown dependent on my job to deliver learning opportunities. The problem is, it isn't. And actually, the problem is manifold, because of the intensely slow adoption curve here, and because of the poor implenmentation of whatever new technology does actually get picked up.
My primary target, and the critical gap in my experience right now, is ASP.NET. While I am extremely comfortable with the C# language and the VS.NET dev environment and its related build/deployment issues, I am still almost a complete newbie when it comes to ASP.NET.
So, with the Internet as my witness, I hereby pledge to get off my expanding seat and dive back into the fray, keeping up with my trench-level views of the industry in general, and making more commentary on some technology specifics.
You'll hold me to that pledge, right?
]]>