Submitted by John Haren on Mon, 2006-02-06 15:03.
Or, How I Learned to Stop Worrying and Love Hibernate
Okee-dokee. To make a very long story short: We've got this thing, see, that we call a DAL. It's kind of a data abstraction layer, but not really; it doesn't do much to 'abstract' data access. It does, however, put all the data access in a common set of packages, if not necessarily behind a common interface. It's not all bad. In fact, it's been useful, and it's gotten us this far. But it is a bit... anemic. And we do have maintenence problems - hundreds and hundreds of 'query modules', some ludicrously specific (bad abstraction! no! no!), most redundant.
Submitted by Gavin Bowman on Mon, 2006-01-23 09:05.
Last week, I started this mini-series on Micro ISV blogging with Why? I put forward the reasons I think Micro ISV founders can benefit from blogging, along with a few reasons not to start a blog.
This week, I decided to try to tackle the "what and when" of Micro ISV blogging. I wouldn’t go so far as to say you need to have a strategy when you start a blog, but sooner or later you will need to think about what you’re doing.
Submitted by Gavin Bowman on Mon, 2006-01-16 09:32.
I’m probably preaching to the converted, but ever since I started blogging, and even more so since I read this forum thread, I’ve wanted to gather my thoughts on this topic.
If you’re trying to start a software company, chances are you already have a million things to do with any given minute. What could possibly convince you to commit any significant chunk of your time to publishing your thoughts online?
Firstly, why not?
Submitted by Gavin Bowman on Mon, 2006-01-09 08:36.
In Your Best Year Yet, Bob Walsh made a few suggestions for taking stock and trying to start the New Year in a stronger position. One of the ideas involved listing lessons learned in the year, and this is the list I came up with when I decided to give it a try.
Submitted by Gavin Bowman on Mon, 2005-12-19 08:57.
I knew there would be more mistakes to write about, maybe not so soon, but I’m glad I’ve finally labelled this one and taken a really good look at it. It’s something I’ve known was an issue for a long time, I just hadn’t let myself see how big it was.
The choice of primary keyword and part of the name of my core product wasn’t heavily researched. I just picked a word I knew meant what I wanted to convey and ran with it. It wasn’t a word I could see any major problems with, and although I was vaguely aware that at some point I’d need to identify and target more suitable keywords for an international audience, I put that thought in a little box and ignored it for most of the last 18 months.
Mistake #6 is choosing a keyword that confuses 99% of your market.
Submitted by Alex Bendig on Thu, 2005-12-15 14:13.
Happy Thursday! This past week has brought tons of excitement at the dayjob. Add to the usual the fact that I will be going on vacation for almost two weeks shortly before the end of the year and we conclude with a newfound mix of emergencies/problems/situations that do make time go by faster than I had wished.
A release will be finished at the end of the year, deadlines are looming and during the midst of everything I spontaneously formed several pet peeves this week. I am probably not going to repeat them here though. Well, maybe, just maybe I will take advantage of our new Anonymous Blog feature for this purpose.
Anyway. What I had hoped to cover this week, as alluded to in last week's post, will have to wait till next week. Instead, with this being the holiday season and all, I decided I am going to take a moment to reflect on my experiences at the dayjob over the last year and come up with a software development wishlist of things to hope/strive for in 2006.
Submitted by Ben Bryant on Wed, 2005-12-14 14:10.
Microsoft chose UCS-2 for its Unicode encoding system when it seemed like a nice and simple fixed size per character; then Unicode promptly outgrew UCS-2. As I said in UTF-8 Versus Windows UNICODE, the early impression of simplicity, in comparison to UTF-8 multibyte encoding, backfired.
What are surrogate pairs?
Surrogate pairs are UTF-16's answer to multibyte encoding. Basically, in the UTF-16 encoding system a Unicode character can be encoded in either one or two 16-bit values; if it is two 16-bit values it is utilizing a "surrogate pair". Surrogate pairs are simple yet they inevitably lead to a great deal of confusion.
Submitted by Alex Bendig on Thu, 2005-12-08 14:44.
A while ago, I found myself stubborningly exclaiming that I will not stop. That was more than two months ago. Time flys when you do not have much of it available. In this week's post I want to take a look back to see what happened since. In addition to that, I think it's a good idea (and the appropriate time) to offer some views (guesses) regarding future developments.
Submitted by Ben Bryant on Mon, 2005-12-05 13:17.
The Enigma Machine was used to encrypt wireless messages by the German regime before and during the Second World War. It was very significant in the Allied victory that they were able not only to decipher the German Enigma's encryption, but to mostly keep it a secret that they had deciphered it. Many soldiers and ships were sacrificed to keep it a secret because the Allies did not want to act on their knowledge unless there was an alternate source that the German's could ascribe the leak to.
Why didn't they want the Germans to know that they knew the system? Because the Germans would have changed it! And it was always a huge challenge to break the new code. The Enigma actually changed many times from when the first cipher machine, Enigma A, came on the market in 1923. The early work at cryptanalysis (to "break the code" of the Enigma) was done in Poland, and then during the war was centered in a very secret English organization that employed 7000 people at its peak.
Submitted by Caleb Tennis on Thu, 2005-12-01 08:19.
In a previous post on the subject, I touched on some thoughts I had based my application needs to keep data in a database over a period of time, without using updates and deletes.
After doing some pencil and paper design, and a lot of thought, I think I figured out the easiest way to implement this.
From a database standpoint, what we really have is a simple one-to-many relationship. For example:
Let’s say we define an employees table. I want to put as little information in here as possible, and yet I want the most amount of static information available in this table as well. For the purpose of this example, let’s just assume that the only thing static about an employee is their name.