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.
Thursday, October 8, 2009
LiquiBase - Database Version Control
If you're a fan of Ruby on Rails, then you probably know about migrations (and what a pain they can be).
Well, LiquiBase promises to bring the same benefits (and headaches) associated with Rails-style migrations. I haven't had a chance to check it out, yet, but I will update when I do.
Well, LiquiBase promises to bring the same benefits (and headaches) associated with Rails-style migrations. I haven't had a chance to check it out, yet, but I will update when I do.
Thursday, September 24, 2009
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.
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.
Thursday, September 3, 2009
Pash - PowerShell for Unix
Regular readers of this blog - both of you (Hi Mom, and that guy in Australia who subscribed to the RSS) - know that I loves me some MS PowerShell. I've called it a "game changer", because it greatly simplifies Windows administration. It is good enough that I've abandoned cygwin on my Windows systems; PowerShell is better than bash.
Well, somebody has released a version of PowerShell that runs on *nix systems: Pash. It builds on Mono, so there is a huge library of objects for it to work on. I don't know how well it works, yet, but I'm certainly going to be trying it.
Well, somebody has released a version of PowerShell that runs on *nix systems: Pash. It builds on Mono, so there is a huge library of objects for it to work on. I don't know how well it works, yet, but I'm certainly going to be trying it.
Monday, August 31, 2009
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.
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.
Subscribe to:
Posts (Atom)