LulzSec and the State of Security

Well, the skiddies sure have been busy, haven't they? Starting with Sony's Playstation Network, to (supposedly) the entire UK 2011 Census, LulzSec has appeared over and over again in the news.

It was announced that a 19-year old mastermind has been arrested in the UK. Well, that should do it, right?

Here's some thoughts about that.

• It is pretty hard to claim that LulzSec even has a leader. They act more like a collective. Anyone can claim to be "LulzSec".
• Most of the attacks have been easy. No "mastermind" is needed.
• It is more likely that the active participants are among the least-sophisticated of hackers. They are just the noisiest.

Those aren't really important, though. What's important is that these vulnerabilities have always been there. LulzSec is only the first to admit that they got to this data. It is all too likely that groups or individuals who were more interested in the data than the publicity got there first.

It isn't as if there hasn't been ample discussion and warnings about security. I've been on the wrong side of expediency too often to believe that. The story is always the same: a variation of "we don't need to worry about that, we need to worry about shipping".

It is a shame that it all came to this, that it takes a bunch of kids using common tools to get past the denials and false assurances of these institutions in order to get the kind of attention that these issues deserve. There will be many innocent victims because institutions who have the resources and knowledge to be among the best failed their most basic function: keeping your money safe.

Operations is as Important as Development

A couple of recent events have inspired me to write this post. The second was Reddit's needing help. The first was an event on my current contract.

My takeaway from Reddit's problem is brief: they finally figured out that just adding new features isn't enough. They have to get their house in order, and they have to take steps to keep it that way. To be fair, I don't know that the source of their problem was poor operational planning, in fact, it sounds like they devote a fair amount of time and effort to it.

The event at work was something of which I've seen way too much. A business wants to roll out a pretty sophisticated reporting application, high availability, super fast - you know, what everyone wants. My part of the whole thing was to determine what hardware and software resources to provide, and then build them out (it's a big enterprise shop, so there's a lot more "fun" associated with it).

It is easy to say "I want multiple web servers", it is another thing to build for multiple web servers. There's a few ways to do it, and what direction is chosen determines what to build.

This particular business not only hadn't really thought about it, they didn't want to think about it. Okay, fine, I can build for that, too - but it is gonna cost them. To the tune of about a half million dollars, just to start. With only a little bit of planning and forethought, by utilizing resources already in place they could get everything they wanted for a few thousand. That's a business decision - if the business can justify that much money, it's their budget, and who am I to complain?

While I may not complain, I can't help but notice that this doesn't really seem like smart business. In that particular case, I really don't know enough about what is going on from the business side to really make that kind of judgement.

However, I have been in enough situations where I did know enough about what is going on to be able to make that judgement. I've seen it enough that I don't want to be in a position where those decisions are made, or diminished. In fact, it is in my best interest to let these shops ignore this importance - because I charge top dollar for coming in and fixing it after the fact. If a shop wants to make a poor business decision which is good for my business...well, that's a good business decision on my part, isn't it?

If you're not bothered by the idea of getting yourself in such a tight bind that you have to shell out thousands of dollars for someone like me (and yes, thousands of dollars is accurate. Sometimes tens of thousands), then save yourself some time and stop reading.

System administration shouldn't be considered after the fact. It shouldn't be considered a necessary evil. It deserves as much prominence and dedication as any other part of the development process. An application isn't just the application that is installed or written - what it is running on is just as important.

System administration has it's own demands,it's own skillsets, it's own schedule, and it's own rhythm. This should be recognized up-front, and it should be given first-class priority. I'm probably being repetitious at this point, but it seems like it really isn't appreciated.

So, I'll say it again: too many businesses, large and small, waste money and time because they don't recognize the importance of their operations, and treat them as afterthoughts. Too many businesses limit themselves, their options, their very potential, because they don't recognize this.

I started to write this with an eye towards specific steps, specific considerations, and a lot of ideas to think about for implementing this. As I wrote, though, it only became clearer that the first step was pointing out what doesn't seem obvious: operations are important. Learn that, know that, believe that, and live that, and you won't have to worry about paying someone like me a ridiculous amount of money when it is least convenient to you.

Ignore this, and that's fine with me. My contact info is to the right, and I sincerely hope to hear from you.

I Want an Online-persona Manager

There's been a lot of hubbub about Facebook and its changing privacy settings. The short version is that they are changing them to the advantage of people who want to make a buck out of you and your friends. It didn't start out that way, and the change has people in a bit of an uproar.

Thing is, Facebook does serve a valuable function - otherwise there would be nothing to exploit. An easy way to keep a business account, and a personal account. Many people use LinkedIn (for professional contacts) and Facebook (for personal) in this manner, including myself.

What the Facebook uproar is making clear is that people value the partitions they build into their lives, and want those partitions maintained online. Another thing that is clear is that as users, we can be sure that policies will change, and we won't like some of those changes.

I don't want to quit Facebook. I like Facebook, for what it is. I don't begrudge Zuckerberg a few bucks off of me, as long as he provides a service I want to use.

What I want is an easier way to manage my profiles, so that I not only have control over what's published, and where, and I want it to be easy.

I want to maintain my own profiles in a centralized location - my hard drive, my backup.

I want to write something once, and then choose, with high granularity, where it will be published.

I want it to be universal, and work with damn near everything.

I want it to be simple, with one interface, like Pidgin does for IM.

I want it to be scriptable, because by now I'm just being greedy :)

I don't want project Diaspora. I'm happy for the kids, and I wish them well, but all they promise is that I'll either have to fire up a server for myself, or I'll have to trust someone else. Again.

I trust my laptop. I trust my mobile phone (sort of). I trust my thumb drive. I trust TrueCrypt. It is my data, and I should control it.

There's a reason businesses try to find out so much about us: it has value. Google has the luxury to walk away from the extra revenue; they're getting enough.

Interestingly enough, Microsoft has an initiative that addresses some of the problem. Called U-Prove, it is BSD-licensed to help drive adoption. It primarily deals with managing both identity and authorization in financial transactions - I don't know if it could be adapted to social sites. This Ars article goes into greater depth.

I dinked around with building something like this on my own, but honestly, it looks like a bit more work than I can tackle right now. So, if there's somebody out there that thinks is a good idea, and has the wherewithal to pull it off, please steal this idea - I'll be one of your early adopters, I promise.

Update: I came up with another way to describe it while discussing this privately (Hi, Tracey!):

I've got six accounts in Outlook right now, all pointing to different places. My personal domains don't know about my google addresses, and heck, my google addresses don't even "know" about one another. (Reading the Spam folders for each one is an education in targeted advertising.) I want the same thing, only for the various social networks.

Google Chrome Beta 4

I installed Google Chrome today, since I saw that the latest beta was out. I'm not much of a browser fanboy, so this was my first spin with it.

It's fast.

Very fast.

As in, it seems like I went from DSL to fiber.

I haven't run into any rendering issues, but I haven't tried banking yet, either. It doesn't have nearly the plethora of plugins that Firefox does. For day to day browsing, though, this thing is looking pretty good.

IronScheme Hits RC1

Given my rediscovered enjoyment of parenthesis-based languages, I noted that IronScheme, an R6RS implementation on MS' CLR, has hit RC1.

Although, really, if I were to choose a functional language for the CLR, it would be F#. Fully supported by MS, decent IDE support...unless there is something particularly compelling about IronScheme, F# would be the one to choose.

Eclipse and Clojure Unit Testing

So far, I'm enjoying my little Clojure projects. The biggest weakness is the IDE, NetBeans, specifically. I haven't and probably won't bother with the emacs version. I'm sure there's things about it that work better, but I'm way too spoiled.

To be fair, the NetBeans plugin is in alpha state. It should get better - this is just a snapshot at this point in time.

As I've worked on this intermediate app, I've had occasion to go back and modify some of the java code I'd already written. Given all the refactoring and testing handholding which NetBeans provides, making those changes was pretty easy.

Here's the world in which I'm living: To get unit tests even somewhat integrated, I call and organize them from main.

(ns some-ns.main
    (:gen-class)
  (:use
    clojure.contrib.test-is))

(defn -main []
  (run-tests
    'some-ns.someclass
    'some-ns.otherclass
))

Because of the IDE integration differences, I can't say that I'm more productive in Clojure. A huge difference is highlighting syntax errors. In Java, they pop up immediately and are easily dealt with. In Clojure, I have to compile before I find out I fat-fingered something.

Debugging is similar. No breakpoints and horrific stack-traces. A good chunk of my code is devoted to logging (which is good and all, but c'mon).

I'm sure things will improve over time. Like I said, the plug-in is alpha. If the language gains much momentum, I expect to see improvements. I have the feeling that it won't gain enough to compare to the ease of Java (I can't believe I just typed that) overall.

Overall, I'm enjoying the experience. I am accomplishing a lot, pretty quickly, and it seems like there is a lot less jumping around trying to keep all the different parts working together.

The Four Quadrants of Technical Debt

Martin Fowler has a piece breaking down "Technical Debt", i.e., shortcuts you take now will have to be "paid back" in the future.

The argument was made that some Technical Debt was not only inevitable, it was desirable. If taking on that debt meant making a ship date, then that debt was worthwhile.

The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the code-base.

He also provides a nice graphic breakdown, worth reading. Check it out.

Considering Clojure

I've been looking at clojure for awhile, now. I liked lisp, back in the day, but never got particularly good at it. Since then, I've done some minor projects in Scheme (Chicken scheme, to be specific). The syntax and programming styles really "did it" for me. Problems just seemed simpler to solve.

When I was working on an earlier revision of this project in .NET, I passed up on F#. I used it for some small test apps, liked it a lot, but decided against it. The main reason is that nobody else is using it. This might change with its inclusion in VS.NET 2010, but I'm not going to hold my breath. Besides, C# has a lot of functional-like syntax these days, so while I may miss some of the F# sugar (pattern matching, for example), I don't feel all that hemmed in with C#.

This next chunk of code I have to write for my little indexing project is discrete from the rest of the project. If clojure doesn't take off as more than an interesting niche language, I could easily find myself replacing it with bog-standard Java.

'Cause I have to admit it: Java sucks. It isn't that it is hard, it's that it is a pain in the ass. In some ways, I preferred programming in C - I spent a lot less time working, it seems. Maybe because I did so much in C; I don't know. I do know that just about every language I've tried since then (except PIC) has been less of a hassle.

I do like all the JVM application containers, though. To me, that's the real winner for Java.

Which leaves me with the whole "changing horses in midstream" problem. I really should write the whole thing in one language. You wouldn't think that would be too much to ask, would you? I certainly wouldn't hesitate to ask it of someone else.

So, I'll probably keep poking around through the tutorial. I may end up with working code which I end up using for the next bit. At the very least, I'll have a good idea as to whether or not this was a good idea.

The Importance of Other Stuff

There haven't been a lot of updates around here, lately, and for that I apologize.

Ya see, I've been busy. I won't go into the specifics. I'll only say that I haven't been poking at computers that much this month because I've been doing Other Stuff.

Given the fast and ever-changing nature of this business, it can be very easy to get caught up trying to keep up with everything. There's always a new technology, a new product, or even just a new version of existing products. There's also all of the tech that one doesn't know anything about, but would be very useful to know.

That's just it, though. Nobody can keep up with it all; there's just too much. A long time ago (get off my lawn!), I concluded that I would commit as little as possible to memory. I focus on the overall patterns, but the specifics tend to be ephemeral, obsolete before you ever get to use them again. If I do memorize something, it is because I use it all of the time. The most important thing I've learned is how to find the answer quickly, even when I've already answered that particular question. (Putting it in a blog doesn't hurt, either.)

There's just so much more to the world. It is a shame to miss it.

Well hey, maybe you're young, and hungry, and this is all you want to do. Okay, that's your call, but you're limiting yourself in the long run. Not just in a "there's more to life" kind of way, but professionally.

You see, all of this tech is about people. Not as "lusers", but as people. The most successful technology isn't the "cool" technology, it's the tools which help people do what people have always done: talk to other people.

They say that a business is about the people. That isn't entirely true. If it were, then we'd still have huge secretarial pools. It is about the interactions between those people. Outside of improving the overall process, the boss isn't interested in what tools you used to get those numbers, only that you got those numbers and they are correct.

There's an attitude among too many of the people in this field that users are stupid. Worse still are the ones who believe that their success in this field translates to success in other fields. The one commonality among them is that they don't do anything else. They don't leave their comfort zones, they forget what it is like to be the least knowledgeable person in the room.

That's why it is important to do Other Stuff.

Where's That File?

This post starts out with a reading of another blog, but it isn't outright babble. It's about what I'm working on.

The author of this article claims "you have to think of content entirely abstractly". While there is some exposition as to what it should look like, it is very vague: "your system should be capable of managing any kind of content."

Fair enough, but how?

Well, that's what I've been working on. I think that the various types of data are best handled by programs specifically designed to handle that data. What we as users need is an easy way to find it.

The current solutions tend to involve centralization, synchronization, and search. You're supposed to keep all the important data centralized, if you need to organize it your own way then you synchronize it, and if you're looking for something you search for it.

Which is great, except that users don't do this, because it all sucks.

If I download file from the internet, that file exists in two places which I can get to. My download folder, and the original link. If I copy it up to a CMS, now it is in three places. If that CMS is backed up, it exists in four places. Copy it to a thumb drive? Now I'm up to five.

Five copies of the same file, in locations which are all equally valid, and all have their strengths and weaknesses. Between them, the data is unlikely to be completely irretrievable.

Now, as a user, all I want to know is "where's that file?" (thus the name of the project)

The author of the original article was correct in that the only important thing is the metadata. What he doesn't seem to get is that the metadata is the only content which needs to be managed.

Currently, the problem I'm solving is strictly a question of duplicate files on the network. I have files that I know must be backed up, but I don't know where all of those copies are. I don't want too many copies, because storage costs are on a rising curve: Each additional terabyte costs more than the previous terabyte.

Turns out, solving this problem isn't easy (my first naive implementations didn't scale), and a whole bunch of the work can be extended to other storage sources.

Having that, though, the next obvious step is to include personal metadata (tags, descriptions) to the files. You have to collect and index metadata, anyway (file name, size, etc.), so why not add user metadata, too?

What I'd expect to see at that point is a UI which reflects the various metadata. If I'm looking for my resume, I should be able to not only find "resume.doc", I should know about all of the copies of "resume.doc" I know about, even if I can't get to them. I'd prefer that the "nearest" one be highlighted in some way, things like that.

What I'd like to do after that (as if I didn't want to do enough), is assign rules to various tags. If I label something with "important", then it should be included in a special backup/sync/whatever. Again, this isn't something that will be particularly difficult, but will require effort.

Well, that's cool, but what about other storage sources? Those are a bit harder, and generally specific to that storage (email, for example). However, things like links to articles and downloads is pretty straightforward, and shouldn't be too hard to include.

Where am I now?

Heh. I mentioned that looking for duplicate files is harder than I thought it would be. I'm actually on my third try. The first one was when I thought "I can do this with a script", the second was with .NET, where I aimed bigger, but found not nearly big enough.

So, I've just completed the work on the file crawler, and the next bit is submitting the crawl results to the index. I've done this part before, and I don't expect it to be particularly hard, but I have to find the time for it. After that, something resembling a UI (I am trying to solve a problem), then put the whole thing out there with a big fat "alpha" disclaimer (probably Apache license, since I'm using so much of their stuff).

And that's what I'm doing, and where I'm at.

IT, Users, and Communication

I was going to let this article slide, and not get all meta-bloggy about it, but the rebuttal really tweaked me. It's all about what users get to install on their work machines, and IT's reaction.

They both miss the point, I think.

Mr. Manjoo related a story about Firefox, and the crowd cheered. If there was really that much demand for it, then it was a failure on the IT department's part to know that it was wanted, and if they knew that, not at least acknowledging it clearly. There's plenty of good reasons not to upgrade.

What Mr. Manjoo missed is that there are tradeoffs to the freedom to install whatever you want, most of them related to support. A lot of IT policy is driven by how much they have to provide that support. Less money means coarser support - heavily locked down machines, aggressive re-imaging, or similar. Things that don't require a lot of people time.

The confirmation bias that both articles triggered in me, though, was that it clearly showed that in neither case is the IT department and the users communicating.

Good IT is hard, not just because of the technology involved, but because you have to make long term decisions which will permit you to react to users ever-changing needs and wants.

Remember, we're here for them, not the other way around. When I walk into a shop that doesn't live that attitude, I know I'll find a lot of problems.

Digital Sharecropping? Hah!

Jeff Atwood of CodingHorror seems to have a problem with user-generated content. He calls it "digital sharecropping". He includes a black and white photo of black people working a dusty field, just in case you didn't get the reference.

The gist of his analogy goes like this:

• Users put their own work into building their particular segment of a much larger site.
• The much larger site puts ads next to the work, and reaps profits.
• The user receives nothing in return.

It's that last part that isn't true. The site provides a cheap and easy means of publishing on the internet - much easier than doing it all yourself. This particular generation differentiates itself from GeoCities, et. al., by providing additional tools for tracking related users and topics.

I think few of the people who publish on these sites are unaware that the hoster is trying to make money off of their work. At the beginning of his article, he repeats a story about a woman who contributes to a site. She calls it a "labor of love".

I think she knows exactly what she is doing. It's a hobby, it keeps her busy, and satisfied. What is so difficult to understand about that?

I don't begrude venues the opportunity to make a profit for providing a comfortable environment. I know of few people who do (you dirty smelly hippie commies!) To be honest, I'm glad that Mr. Atwood at least thinks about the topic, but really: it isn't all that big a deal.

Java's Lots of Little Files

I ran into this article about "Next Generation Java Programming Style", at YCombinator. There was some interesting discussion about the overall effectiveness of these suggestions.

Part of the discussion involved commenter Xixi asking if anyone had followed point #5, "Use many, many objects with many interfaces". It turns out, I've been following that model. I started to reply there, but I recognized a blog post after a bit.

Here's my general workflow, and I've found it to be quite effective.

The linked-to article refers to interfaces as "roles", and that's probably the easiest way to think of them.

If I have a few related items which need to be handled, I first create an interface for it: IMessage (I realize it isn't the java convention to prefix interfaces with "I", but I prefer it - especially with as many as I ended up with). Add in a few obvious functions, send, recv.

Create the concrete class (the actual implementation): FooMessage. In this case, the messages would deal with "Foo". So, it has send, recv, and say count. Gotta know how many Foos we have, right?

Next up, the test class - but I'll get to it in a moment. This is where I write it in the overall workflow, but it doesn't make as much sense without talking about Mocks.

Last, I write the mock class for the concrete class. It also implements IMessage, but most of the implementation is empty - just accepts the parameter, and maybe spits back a default value.

Which brings us back to the test class. Since I refer to everything via its interface, using those mocks is easy. In FooMessageTest, I use the concrete class FooMessage, and a whole bunch of mocks. Generally, everything but the class being tested can use mocks, so testing ends up nicely isolated and repeatable.

In practice, concrete classes implement several interfaces (IFoo, specifying count, so you could have IBar, which specifies weight.)

Okay, this was a lot of work up-front, and I'll be honest: I approached it with some concern that it wouldn't pay off.

Well, it has. Refactoring, with the assistance of NetBeans, has been a breeze. Adding in new, or modifying old functionality has been super-easy. Yes, there's a few hangups, but they tend to revolve around my lack of planning than the overall process. I don't feel as "free" as when I use Ruby, but I don't feel held up by the language or its environment.

The hardest part has been maintaining discipline. It is really easy to think that this particular class doesn't need an interface, or a mock, etc - but that is no different than any other methodology.

Fun With Projects!

Way back in the day, around April or so, I was talking about a project which was taking up my time. Yes, it is still coming along nicely. We're playing nice with ActiveMQ, Java, the whole bit.

It has taken awhile to get as far as I have. It isn't that the underlying concept is all that difficult ("index files"), it is the scale at which I want to do it. So, there's been a lot of internal abstraction going on, with all of the attendant complexity (lots of little files).

What I'm really happy about is the overall process I've been following. I've been a proponent of tests and mocks, and I've used them a lot in my projects before. The one mistake I always made, that everyone always makes, is losing discipline - giving into the urge to cut a corner. After all, I won't need a mock for that class, it's too simple, right?

I haven't done that this time around. It is really paying off. I haven't been able to devote 100% of my time to this, so I've walked away more than once. I have had no trouble picking up where I was. New pieces work excellently with older pieces, and I barely question the predictability of anything I've done so far.

There's more work to do, of course. I see the light at the end of the tunnel, though. There's some obvious performance changes I can make, but once I've got the basic "duplicate files" functionality going, I'll post it all someplace.

Sticking with XP

I was reading this CodingHorror piece, and for the most part thought it was ho-hum. Windows 7 is nice, and he finds a nice way to dig at it ("Vista service pack"). Clever, or would be if I hadn't heard it a few times already. Maybe it's new to you, I dunno, that's not the point.

There was a bit in it that I totally disagreed with:

It's important to me not because I am an operating system fanboy, but mostly because I want the world to get the hell off Windows XP. A world where people regularly use 9 year old operating systems is not a healthy computing ecosystem. Nobody is forcing anyone to use Windows, of course, but given the fundamental inertia in most people's computing choices, the lack of a compelling Windows upgrade path is a dangerous thing.

Different definitions of "dangerous".

How is slow change dangerous to an ecosystem? It might be dangerous for itself, i.e., the Windows franchise, but the ecosystem seems to have not only survived, but thrived. Not only did Apple take total advantage of MS' lapse, but the Linux desktop looks better and better (typing this on Ubuntu). Within the Windows' desktop universe, there is a huge software library specific to XP, not just Windows. Tweaks, utilities, and documentation galore.

XP was some good shit.

Now? Now I'm going to keep any XP machines around, until they absolutely have to be upgrade to gain functionality. Just out of spite. Er, if I can find any, that is.

Java XML "support"

Like many software projects written these days, I'm finding using XML unavoidable. I'd always wondered why Java programmers always seemed so grumpy about XML, and now I know.

Java XML support sucks.

I'd never really appreciated .NET's support for XML. A few pain-in-the-ass points, but for the most part pretty easy to use. Ruby makes it way too easy, and comes closest to how it "should" be done.

It started with serialization. I need some way to store the state of an object so I can send it over the wire. Java has a built-in binary serializer which works very well. It doesn't matter if the fields are private, or whatever, it'll dump them out and read them back in. A couple of pain points, but pretty easy to use, much like .NET's serialization. I figured that serializing to XML would be just as easy.

I can be so naive.

Everyplace I looked said to use XMLEncoder. Okee dokee, except that the equivalent code doesn't give equivalent results. Do some digging, and it turns out the binary and XML serializers use completely different mechanisms. Now, there's probably some pointy-headed academic someplace who is satisfied that the XML serializer meets some standard. If it means re-writing your code in such a way as to make it more difficult to maintain, then you're doing it wrong. Especially when a not only do competing languages do it in an elegantish manner, but you have an implementation which does it well, too.

You know, the source code is open. Someone with more time oughta look into that.

Anyways, since it all blows so hard, I've got some extra work implementing my own serialization conventions. I've got it implemented about halfway through at the time of this writing. It shouldn't take much longer to finish.

Learning Java, Still

I've been hammering away at both getting the project along (and it is coming along nicely), while learning Java (also coming along nicely). I've done enough that I've got some opinions about Java. Maybe I'm just doing things wrong, and whatever old Java sages stumble across this post will just shake their heads at the n00b.

Today's complaint - exceptions

First, I wanna complain about exceptions in Java. I like exceptions. I like code that blows up in a predictable, informative, and containable manner. At first, when I was having to declare all the potential exceptions a method could throw, I was annoyed. Then, I came to appreciate it. I had a detailed list of broad categories of things that could go kerblooie.

That is totally awesome.

So, there I was, hard at work, not understanding why I wasn't getting the results I was expecting. Then I noticed the log saying something about an exception, and continuing.

I looked, but I wasn't catching it anywhere. It was an unhandled exception, or at least I wasn't handling it, and I'm the only person I care about when it comes to code.

Dammit, things should blow up, not just continue. What the hell kind of "exception" is that, anyway? They call it "unchecked" (or is it the other way around?). I guess I'm just not smart enough for Java.

All is not suckitude

I'm using NetBeans, this go-round. It runs really well, handles my multi-mon just fine, and holds my hand without getting in the way too much. It isn't as good as Visual Studio - VS just has a bit more "polish" to it (much better autocomplete, for example), but it is easier to get to the guts of NetBeans.

Refactoring in Java is awesome. I have absolutely no fear about renaming things, moving them around, whatever. Since laying things out in both agiley and enterprisey fashion means a lot of little files, this is pretty important. I've been burned by refactoring in VS (but not a recent version), but not once in NetBeans.

Things could be easier, dammit!

Documentation is all over the map. The linux distros used to have this problem (they've gotten much better), where there were just so many options, and no clear consolidated approach. NetBeans packages as much as it can together, of course. This doesn't cover moving to production, or anything like that. I guess it is expecting too much to find documentation geared towards someone who is intent on learning an entire stack at once.

I'll get over the smell

As usual, I'm having fun learning. I've got enough of the basic patterns down that I'm getting a lot done fairly quickly. I'm sure I'm making dozens of beginner mistakes, but hopefully I'm doing a good enough job that those things are easy to find and fix.

I keep getting stuck on the server deployment scenarios. There's just too many of them. Not just app servers, but what those app servers need to provide. The acronyms are very thick.

Just more stuff to hammer on through. I'll keep you posted, of course.

My Online Dumping Ground

I've written a bunch of stuff over the years, of various utility.

And I've lost most of it. No hardship, it is just a pain in the butt to keep track of it.

Anyway, some of it is marginally useful, so I thought I'd set up someplace to host it. It is all BSD-licensed.

You can find it here.

Featured projects (okay, the only projects):

• IIS6 Cmdlets (cmdlets to administer remote IIS6 machines)


• ServerInfo (detailed remote IIS6 configuration information GUI)


• FileInfoExtensions (Things .NET's FileInfo should have, but doesn't)


• Powershell Profile (My profile.ps1. Whoop. It was when the output of my profile exceeded the length of my original profile that I decided to move everything out there)

I can't attest to any great quality for these apps. If nothing else, at least I'll know where they are.

I've been putting snippets of code in this blog, but it isn't too long after that I've posted it that I'm updating the article with a much better script. Rather than do that, I'll just provide a link to the code in the project, with maybe some bits extracted. That FileInfo post was an excellent example: worthwhile code, but loooong.

Microsofting

Oh boy, coding on a Saturday night! What could be more fun?

Well, there's been a little tempest-in-a-teapot about some MS marketing blog being busted as an astroturfing site.

I like the response of the blog:

As for WordPress, I address using Microsoft competitor tools on my about page. Again, it’s not really a secret. You can see the flickr photos and youtube videos right there on the homepage.

All this is to say — you can hate on Microsoft and its advertising all you want … but I’m not sure it’s fair to act like it’s a big GOTCHA! to catch a marketing site being, well, a marketing site.

There's two bits I like about it. First, the obvious in-your-faceness of it.

Next, admitting that they use tools other than MS tools. You know, like the rest of the world. I've always found Redmond's self-rah-rahing and NIH attitude irritating. Microsoft's biggest weaknesses revolve around its isolation from the rest of the community. This is a welcome change. I wonder how long it will take for it to be beaten down?

What If Microsoft Turned A Corner, and No One Was There?

(Disclaimer: MSFT from 1994-2003)

Ran into this today, which argues that Microsoft has turned the corner. Considering that blog tends to be critical of MS, it was worth a read.

Despite my history with MS, I've been pretty much all over the map when it comes to PC-based server tech. Even at MS, I was an early adopter of Linux, and ultimately started my own hosting service on FreeBSD (which failed, but that's another story).

That said, I recently took a new look at MS' 2008 stack (Windows 2008, SQL 2008, VS 2008). It doesn't suck. In fact, it is pretty darn good.

What I liked:
- Powershell. I don't like to throw the term "game changer" around much, but this one is. Between that, and a very rich .NET model, a lot of previously cumbersome tasks are now trivial.
- IIS7. Much more modular, much more programmable (more Powershell)
- VS2008. I've long like MS' IDEs, and this one kicks much butt. Add in ReSharper, and it totally rocks.
- SQL 2008. It scales better, it is easier to manage, and very configurable.
- C# 3.0. I'm a chump for simple lambda syntax.

The biggest difficulties I ran into stemmed not from Microsoft's tech, but from the ecosystem around their technology.

I have found plenty of neat stuff to use, but a lot of it runs under Java. Sure, I could build various bridges from .NET to those tools, but then I have a whole other chunk to maintain. Many of the projects have .NET client, but they tend to be second class.

Why would I want to do things half-ass like that, when I know all too well of the problems that causes?

There's just more happening in the Java/Linux world. If I want to maintain a competitive edge for my customers and myself, it behooves me to use and recommend the better technology. Right now, that isn't Microsoft - and it isn't because of Microsoft, itself.

When I wanted a search server, I could use MS', which works on Windows, or I could use Solr, which runs on Java. When I needed some form of network monitoring, I ran into OpenNMS, and didn't find a lot for Windows . Lately, I wanted a good message queue. Microsoft has one (and it works fine), Java has a selection.

Thus bringing me to the point: it may not matter if MS is getting it. MS isn't capable of doing everything, no matter how efficient and disciplined they get. They need everybody else in order to be a strong presence. Their heavy-handed tactics of the past may have deprived them of what they needed most: people.

They have a strong presence in the enterprise world, and this latest stack will help cement that position. The large organizations tend to move slow, anyway, so being a little behind isn't too big a deal. MS' best tools are best suited to that environment. They aren't going away.

They have the money to ride out their bad reputation. Maybe they can trim more of the fat, and focus a little bit better. In the meantime, they have a lot of ground to make up.