Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2018

Interesting conversation from MacStories today. A feller says he's leaving "Things" because it's not changing enough, not because it's incompetent. There's an important section in Lopp's post about leaving "Things" that the conversation seems to gloss over: Lopp says he's found a better alternative.

Regardless, the topic of the conversation itself is exceptionally useful.

Should customers appreciate polished software?

Here's part of a reply from Daniel Jalkut to Lopp called Stagnation Or Stability? from Bitsplitting.org:

He applauds the app for allowing him to do his work “frictionlessly.” How does a software developer achieve this level of performance? By first building a quality product and then working deliberately over months and years to address the minor issues that remain. Woodworking makes a reasonable analogy: after a chair has been carved and assembled the job is functionally complete. It’s a chair, you can sit in it. It’s done. But customers will gripe with good cause about its crudeness unless the hard work of detailing, sanding, and lacquering are carried out. Only then will it be considered finely crafted.

As a seasoned software manager, I know Lopp appreciates how hard it is to achieve the stability Things has provided for him. But as a user, he’s as excited as any of us to see new, fresh designs. As an onlooker, it’s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted.

So the problem here seems pretty clear -- reusing Jalkut's metaphor perhaps a bit too much, let's say that the "masses" are often happy to have a rough-hewn chair. More importantly, they'd rather have a rough-hewn chair NOW WITH ROUGH-HEWN TABLE!!! than a wonderfully crafted chair.

Many people make do with a Chevy even after they can afford the Benz. Not everyone buys the latest iPhone. Etc etc.

So let's flip the question:

Should programmers appreciate that customers don't always want (aka, "pay for") polish?

Why do developers -- and not just developers, but, in my experience, the better developers -- seem to strive for perfection without a clear business case? Look, let's not get confused. I want polished code, business be damned. But I can also understand the argument that we can't enter the table-using vertical without, well, a table. And if that means our chair is a big ball of mud, all I can really do is suggest that we're going to have a hard time catching up when someone creates polished chairs and tables down the line.

But until that happens and our products are outflanked, no matter how much Little Red Hen I try to be, I'm just Chicken Little to upper management. The worst part? I don't know that they're "wrong" to prefer the rough-hewn chair, just like Lopp does here.

More to the point, how do you know when your chair has enough polish that it's time to move on?

Labels: business, coding, hats of money, quality, style

Finally started seriously scratching a new itch. I really disliked how difficult I'd found it to get a database engine working crossplatform for my C# "hobby" projects with MonoDevelop and, now, Xamarin Studio.

I'd considered using JSON or DataSet's WriteXML method to serialize data, but up until now, I'd been just writing stuff to text files to get hobby projects running more quickly. After using home-grown text file formats for years, though, it seemed dumb not to leverage SQL syntax. Yet every time I tried to find a good, crossplatform solution, I would waste hours not quite finding a great answer.

As I write in the new project's readme...

MVED# was written largely because of setup hurdles encountered attempting to deploy other obvious embedded database solutions for C# crossplatform. SQL Server Express is not crossplatform. SQLite must be installed on Windows and has a few nontrivial setup requirements on OS X, both of which create a clear barrier to entry out of proportion for applications with modest data serialization needs. C#-SQLite is an interesting alternative, but still had issues when I tried it out in May of 2012.

So back in February 24th of this year, I started hacking a database engine. And 121 commits to Bitbucket later, I finally have enough to put up on GitHub. (The GitHub/Bitbucket dynamic is also very interesting...) I can CREATE TABLE, INSERT, DELETE, SELECT, even INNER JOIN. I'm an UPDATE away from 80% of what I use "real" databases to accomplish. Well, if you ignore speed.

It's fun to look back over my commits, as always. There are almost zero commits in June and July, when work took a real turn for the busier. Seems like tons of late night commits. Also some interesting comments about where I was while I was coding...

Admittedly, there are tons of *cough* idiosyncratic behaviors in the engine, but much of this was an enjoyable alternative to the horribly defensive coding you have to do for customer-facing code. If I don't want to support ORs in WHERE clauses yet, well, I don't have to. If I want to support only INNER JOINs at first, that's my "right". Case sensitivity? Whitespace rules? All my decision. Bizarre! Want FLOATs to be stored as conventional DECIMALs for now? No problem (and more accurate too)! Unicode? Not yet! Why not? Because I chose [not] to! I'm drunk with power.

It was a heck of a lot of fun dealing with how to serialize each of the datatypes I'm supporting now. I did take a few old school-ish routes with storage while writing. Every column's length is absolutely fixed (VARCHARs really aren't VAR at all), largely to make the file's format really easy for users to eyeball, probably a leftover from having played around with 6507 assembler too much years ago. I even slap lines of 0x11s between columns to make it super-easy to view. Having easier-to-read files is probably not the best motivation for creating formats, but I'm happy with how it turned out.

Here's a crappy example of a raw "Moore's DataBase File (mdbf)" in the quick file viewer I wrote for the engine (click to see in any real detail).

Figuring out ways to serialize strings and decimal values was, honestly, fun. Doing this without much heavy "cheating" (more accurate would be "researching") was also a refreshing break from "serious" work, as this project is intended to be almost completely for [my] relaxation. Getting close to finished in about a tenth of the lines of C#-SQLite is, well, interesting. There's a lot that's not here. Parsing commands, even when you do get to choose what's syntactically legal, quickly gets, well, ugly. JOINs tend to bust what would otherwise be a pretty simple paradigm for parsing SELECTs -- heck, even SQLite currently doesn't support RIGHT OUTER JOIN. (Actually, reading that page, I feel a little of Hipp's pain (though let's make clear, since I'm talking about both in the same paragraph, that C#-SQLite is a port of SQLite by Noah Hart). GRANT and REVOKE don't mean so much when you're just hitting the file system, do they?)

Ultimately, writing MVED# reminded me a great deal of the shareware app I wrote years back. Eventually, even when you have nobody to answer to, code reaches the point where it's difficult to keep things idealistically organized. (Insert tangent about why it's so much more important to see a candidate's solution to a real-world problem than to simply interview, say, a new graduate about patterns when you're hiring.)

This project was also my first "real-world" use of the GNG Manfiesto. Even though MVED# could have easily gone under LGPL, I think there are going to be times where it's easier to use with the project's files compiled into a single app with new, closed files, so I opted for MPL 2.0 for now. Either way, it's open, demands changes by others to be shared, but allows others to use it as they'd like without compromising their own original, unrelated contributions, just as GNG demands.

Anyhow, to advert a little more plainly, the Minimally Viable Embeddable Datastore in C# (MVED#) or, as I called it as I developed it (since I wasn't worried a whit about performance), Moore's Database, can be found here:

https://github.com/ruffin--/mved/

It's not feature complete yet -- I'd like to sneak an UPDATE command handler in there before I do too much clean-up of existing code, which will be an easy refactor and then edit of the SELECT code -- but it's surprisingly close for what I think I'd like to use it for. A quick class for testing should follow UPDATE.

The code is hilariously simple. Optimizations are almost non-existent. Yet, at the same time, I think it's a horribly accessible codebase. We'll see. I'm going to use it. It works just as well on OS X as Windows, and that's a great start for my apps that need an embedded database solution. I can only assume Xamarin's going to make it pretty easy to use MVED# on Andriod and iOS too.

But okay, fine. I hear what you're thinking. If I have 121 commits and each one is, say, 30-45 minutes (let's go on the high side of that range and say 45 min, though admittedly I wonder how good of an estimate that is), that's 90 hours I didn't spend writing The Next Great Piece of Software with an existing engine. And it's not like I'm done yet. To me, that sort of cuts both ways. I'm surprised I'll be able to get a first functioning database engine in well less than three full-time weeks' of work, and I wonder if I'd waste that much time trying to get existing DBMSes working crossplatform. But then if I'd kept development to a primary platform and used the obvious DBMS engine for it, that's ~90 hours of work and months of free time I'd be ahead of where I am now to release an app for someone.

Regardless, it's been, and hopefully will continue to be, a fun project. Happy hacking.

Labels: coding, F/free, github, gng, mved, open, SqlDbSharp

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Monday, November 25, 2013
Economic [psychological?] prisons This Is Why Poor People's Bad Decisions Make Perfect Sense \| Linda Tirado: I make a lot of poor financial decisions. None of them matter, in the long term. I will never not be poor, so what does it matter if I don't pay a thing and a half this week instead of just one thing? It's not like the sacrifice will result in improved circumstances; the thing holding me back isn't that I blow five bucks at Wendy's. It's that now that I have proven that I am a Poor Person that is all that I am or ever will be. It is not worth it to me to live a bleak life devoid of small pleasures so that one day I can make a single large purchase. I will never have large pleasures to hold on to. There's a certain pull to live what bits of life you can while there's money in your pocket, because no matter how responsible you are you will be broke in three days anyway. When you never have enough money it ceases to have meaning. I imagine having a lot of it is the same thing. Reminds me of Ice-T's "Escape from the Killing Fields". You don't have to think she's talking great sense, but I think it's only fair to assume she's talking from experience. Even if it's ostensibly smarter to be careful with your cash, how many times does it have to seem like saving doesn't work out before you start believing it's not worth the trouble? Her explanation for tobacco as the best way to self-medicate also seems, if not particularly smart, at least arguable. Being poor fosters (not creates; fosters) specific mindsets that, like hunger, you have to experience to understand. Labels: hats of money, Other Stuff posted by ruffin at 11/25/2013 08:35:00 PM
0 comments
Saturday, November 23, 2013
Why does Apple ignore left-handers? I noticed on the fourth generation iPod touch that the volume buttons are very difficult to operate with a single hand. I had an earlier touch that wasn't as noticeably difficult to use. I guess Apple favors thin over ease of use for 14% of the population. Appropriately enough, I was told this is a first-world problem, and let it go [for a while]. Well, the first-world problems continue. When I shoot pictures and video on the iPhone 5S (and everything before), it doesn't seem to have a good concept of when it's upside-down. Better put, it doesn't know which side is being held down when I do a landscape. I mean, there's no a priori right-side up when you lean something on its side. When I hold the iPhone in landscape, I position it to unlock the screen with a left-handed flick, and the camera snap/record button is on the left. If I email someone a picture, bam, it's upside-down. Folks don't enjoy watching upside-down movies. That's just sad. I'm always surprised how often Apple fails at easy, obvious, commonly used things but still gets away with the reputation that they sweat the details. I mean, they do a great job when they want to get a concept just right, but if they don't think something's worth checking out -- or just miss it entirely; you know, like left-handed use -- you're toast. Labels: apple fail, iphone, ipod posted by ruffin at 11/23/2013 11:25:00 AM
0 comments
Friday, November 22, 2013
Windows 8.1 listens to local searches? Scroogled, indeed. Okay, admittedly I really hope to bag a Scroogled coffee mug if they come back in stock, but the irony of learning this the same day I order my Scroogled shirt is thick. Windows 8.1's 'Hero' ads -- brought to you by stealthy snooping \| Microsoft windows - InfoWorld: Here's the part Microsoft doesn't tell you -- the part the tech press neglects to mention: Bing Smart Search works by snooping on the searches you perform on your Windows 8.1 computer (there's no Smart Search in Windows 8). Windows watches as you run local searches. Unless you specifically, explicitly search for Settings or Files, Smart Search bundles up all of your search terms and sends them to Bing, along with whatever tracking information Windows has at hand. (Perhaps your Windows account?) [emphasis mine -mfn] Whoa! Local as in, "kittens.gif" searches? Certainly I've got that wrong. Right? Labels: microsoft, privacy posted by ruffin at 11/22/2013 02:15:00 AM
0 comments
Thursday, November 21, 2013
RLY? "This playlist is not eligible for iCloud" At first I thought perhaps I had a playlist that included a suspicious file. I have a good deal of taper band shows in WAV format that I could understand Apple not wanting to promote, or having to include as part of the Match contract that they wouldn't support unknown .WAV or larger files. But that's not it at all. It's some Apple coders and/or their manager. Really, Apple? Playlists are just pointers. All you have to do for mine is take files from my "picks" playlist (my favorite songs) and subtract those in my "not safe aloud" list (words that curse or deal with, well, themes I don't want blasting around kids or from my car window). Perhaps there's some edge case -- there's always some edge case -- with multiple layers of smart playlists that's difficult to support, but to say that nested playlists aren't supported, full stop, well, as someone who just kludgily added INNER JOINS to a home-rolled dbms and knows it's not that big a deal, this iCloud limitation is sorry programming, Apple. Support the 80% of us whose embedded lists aren't complicated, and only have the 20% that are edge case users to feel this pain: "This smart playlists contains complex rules that are not currently supported in the cloud." Sheesh. 80/20 Apple, 80/20. Update: I'm having more problems, now a playlist that's a subset of a playlist that's in iCloud, but for which I'm getting... And it looks like I'm not alone experiencing seemingly avoidable errors like this. Labels: apple fail, iTunes posted by ruffin at 11/21/2013 11:09:00 AM
0 comments
Wednesday, November 20, 2013
Deliberate development: Stability or hubris? Interesting conversation from MacStories today. A feller says he's leaving "Things" because it's not changing enough, not because it's incompetent. There's an important section in Lopp's post about leaving "Things" that the conversation seems to gloss over: Lopp says he's found a better alternative. Regardless, the topic of the conversation itself is exceptionally useful. Should customers appreciate polished software? Here's part of a reply from Daniel Jalkut to Lopp called Stagnation Or Stability? from Bitsplitting.org: He applauds the app for allowing him to do his work “frictionlessly.” How does a software developer achieve this level of performance? By first building a quality product and then working deliberately over months and years to address the minor issues that remain. Woodworking makes a reasonable analogy: after a chair has been carved and assembled the job is functionally complete. It’s a chair, you can sit in it. It’s done. But customers will gripe with good cause about its crudeness unless the hard work of detailing, sanding, and lacquering are carried out. Only then will it be considered finely crafted. As a seasoned software manager, I know Lopp appreciates how hard it is to achieve the stability Things has provided for him. But as a user, he’s as excited as any of us to see new, fresh designs. As an onlooker, it’s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted. So the problem here seems pretty clear -- reusing Jalkut's metaphor perhaps a bit too much, let's say that the "masses" are often happy to have a rough-hewn chair. More importantly, they'd rather have a rough-hewn chair NOW WITH ROUGH-HEWN TABLE!!! than a wonderfully crafted chair. Many people make do with a Chevy even after they can afford the Benz. Not everyone buys the latest iPhone. Etc etc. So let's flip the question: Should programmers appreciate that customers don't always want (aka, "pay for") polish? Why do developers -- and not just developers, but, in my experience, the better developers -- seem to strive for perfection without a clear business case? Look, let's not get confused. I want polished code, business be damned. But I can also understand the argument that we can't enter the table-using vertical without, well, a table. And if that means our chair is a big ball of mud, all I can really do is suggest that we're going to have a hard time catching up when someone creates polished chairs and tables down the line. But until that happens and our products are outflanked, no matter how much Little Red Hen I try to be, I'm just Chicken Little to upper management. The worst part? I don't know that they're "wrong" to prefer the rough-hewn chair, just like Lopp does here. More to the point, how do you know when your chair has enough polish that it's time to move on? Labels: business, coding, hats of money, quality, style posted by ruffin at 11/20/2013 10:20:00 AM
0 comments
Monday, November 18, 2013
Do you overuse design patterns? Stop. Design Patterns Isn’t a Golden Hammer (from Phil Haack): All too often, I’ve encountered code that uses a pattern because the developer felt he should use a pattern there, not because he needed the pattern. Not every developer understands that patterns add complexity to a solution. ... The important concept to understand is that Design Patterns are descriptive not prescriptive. They aren’t intended to instruct how one should design a system, but merely describe successful designs that have worked in the past for common problems. Welcome to where I work right now. In a post that links, Haack gets waaay too close to home describing what this can feel like. If you need to instantiate a factory, implement an adapter class and use a bridge to the toilet just to [go No. 2], then you probably live with a developer with a premature generalization problem. What I've heard to explain mindless pattern usage is that many of our folks don't understand when you've gone from code that doesn't deserve major abstraction to code that does. While ultimately that's a hiring problem (you don't have coders competent enough to know how to factor their code), that fact doesn't help you solve the problems your current staff already has. That's a tough quandary -- do you beat your head against the wall trying to teach those who seemingly can't be taught, spending yet more time making sure they go back to clean up their messes as they slog along -- or do you simply force them to follow the patterns all... the... time? I think you have to try to teach folks, and if they continually can't handle refactoring, you have a reason to let them go. It's expensive to fire and hire, but it's got to be more expensive to keep using folks who can't code. Great quote from Erich Gamma in that same post: Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. So far, I love this series of posts by Haack... Design Patterns Isn’t [sic] a Golden Hammer Avoid Premature Generalization Avoid Premature Standardization He apparently also has some posts on avoiding premature optimization. I'm just starting in on reading the series, and will probably feel compelled to blog about them a few more times... Labels: coding, Haack, style posted by ruffin at 11/18/2013 07:02:00 AM
0 comments
Thursday, November 14, 2013
"Microsoft’s OpenXML SDK is [like]... Assembly language" Making OpenXML Easy with ClosedXML: Microsoft’s OpenXML SDK is to OpenXML documents like the Assembly language is to processors. You can use it to get your work done but it takes a tremendous amount of effort to do anything. Exceptionally well put. It's open qua all in XML, but only in the manner that Microsoft Word is open because I can see its bytecodes. Labels: hats of money, microsoft, ooxml, open posted by ruffin at 11/14/2013 02:20:00 PM
0 comments
Wednesday, November 06, 2013
Gates on technology "flattening" the world An exclusive interview with Bill Gates - FT.com: “Fine, go to those Bangalore Infosys centres, but just for the hell of it go three miles aside and go look at the guy living with no toilet, no running water,” Gates says now. “The world is not flat and PCs are not, in the hierarchy of human needs, in the first five rungs.” It's flat, sure, but flat from the perspective of moving capital, not flat in the sense of socioeconomic equality. Gates sure gets that. Honestly, picking malaria as your primary humanitarian fight is brilliant in its sensibility. It's already been eradicated in some geographies, so it's a winnable fight. It's a big enough issue that populations have evolved to where that it's better to throw away a quarter of your otherwise viable progeny to give two-thirds of those who do make it resistance to the disease. And it's cheap & low tech -- simply giving nets "can reduce the chance of children catching malaria by 20 percent" (unicef). And a how much is a cure if you do get malaria? Ran me $6 including the doctor's home visit. I'm not sure you don't want this guy running, if not Microsoft, then Windows. Labels: gates, malaria, microsoft, windows posted by ruffin at 11/06/2013 12:22:00 PM
0 comments
Tuesday, November 05, 2013
Using FTPS from C# The Alex FTPS Client isn't too bad. I enjoyed reading its exchange with my local FileZilla server. (000018)11/5/2013 9:23:05 AM - joe.dirt (::1)> CLNT AlexFTPS (000018)11/5/2013 9:23:05 AM - joe.dirt (::1)> 200 Don't care Ouch. ;^) Other than a small problem with FileZilla Server that I worked around (quickly and dirtily -- btw, that's a link to the patches page, though the project seems in stasis. The guy is still around, and there are recent twitter posts on his company page, but not much on the FTPS front. If the patch is gone, though, that's probably why -- integrated or erased), the FTPS package seems to work well. Labels: c#, filezilla, ftp posted by ruffin at 11/05/2013 09:24:00 AM
0 comments
Saturday, November 02, 2013
MVED# (Minimally Viable Embeddable Database in C#) on GitHub. Finally started seriously scratching a new itch. I really disliked how difficult I'd found it to get a database engine working crossplatform for my C# "hobby" projects with MonoDevelop and, now, Xamarin Studio. I'd considered using JSON or DataSet's WriteXML method to serialize data, but up until now, I'd been just writing stuff to text files to get hobby projects running more quickly. After using home-grown text file formats for years, though, it seemed dumb not to leverage SQL syntax. Yet every time I tried to find a good, crossplatform solution, I would waste hours not quite finding a great answer. As I write in the new project's readme... MVED# was written largely because of setup hurdles encountered attempting to deploy other obvious embedded database solutions for C# crossplatform. SQL Server Express is not crossplatform. SQLite must be installed on Windows and has a few nontrivial setup requirements on OS X, both of which create a clear barrier to entry out of proportion for applications with modest data serialization needs. C#-SQLite is an interesting alternative, but still had issues when I tried it out in May of 2012. So back in February 24th of this year, I started hacking a database engine. And 121 commits to Bitbucket later, I finally have enough to put up on GitHub. (The GitHub/Bitbucket dynamic is also very interesting...) I can CREATE TABLE, INSERT, DELETE, SELECT, even INNER JOIN. I'm an UPDATE away from 80% of what I use "real" databases to accomplish. Well, if you ignore speed. It's fun to look back over my commits, as always. There are almost zero commits in June and July, when work took a real turn for the busier. Seems like tons of late night commits. Also some interesting comments about where I was while I was coding... Admittedly, there are tons of *cough* idiosyncratic behaviors in the engine, but much of this was an enjoyable alternative to the horribly defensive coding you have to do for customer-facing code. If I don't want to support ORs in WHERE clauses yet, well, I don't have to. If I want to support only INNER JOINs at first, that's my "right". Case sensitivity? Whitespace rules? All my decision. Bizarre! Want FLOATs to be stored as conventional DECIMALs for now? No problem (and more accurate too)! Unicode? Not yet! Why not? Because I chose [not] to! I'm drunk with power. It was a heck of a lot of fun dealing with how to serialize each of the datatypes I'm supporting now. I did take a few old school-ish routes with storage while writing. Every column's length is absolutely fixed (VARCHARs really aren't VAR at all), largely to make the file's format really easy for users to eyeball, probably a leftover from having played around with 6507 assembler too much years ago. I even slap lines of 0x11s between columns to make it super-easy to view. Having easier-to-read files is probably not the best motivation for creating formats, but I'm happy with how it turned out. Here's a crappy example of a raw "Moore's DataBase File (mdbf)" in the quick file viewer I wrote for the engine (click to see in any real detail). Figuring out ways to serialize strings and decimal values was, honestly, fun. Doing this without much heavy "cheating" (more accurate would be "researching") was also a refreshing break from "serious" work, as this project is intended to be almost completely for [my] relaxation. Getting close to finished in about a tenth of the lines of C#-SQLite is, well, interesting. There's a lot that's not here. Parsing commands, even when you do get to choose what's syntactically legal, quickly gets, well, ugly. JOINs tend to bust what would otherwise be a pretty simple paradigm for parsing SELECTs -- heck, even SQLite currently doesn't support RIGHT OUTER JOIN. (Actually, reading that page, I feel a little of Hipp's pain (though let's make clear, since I'm talking about both in the same paragraph, that C#-SQLite is a port of SQLite by Noah Hart). GRANT and REVOKE don't mean so much when you're just hitting the file system, do they?) Ultimately, writing MVED# reminded me a great deal of the shareware app I wrote years back. Eventually, even when you have nobody to answer to, code reaches the point where it's difficult to keep things idealistically organized. (Insert tangent about why it's so much more important to see a candidate's solution to a real-world problem than to simply interview, say, a new graduate about patterns when you're hiring.) This project was also my first "real-world" use of the GNG Manfiesto. Even though MVED# could have easily gone under LGPL, I think there are going to be times where it's easier to use with the project's files compiled into a single app with new, closed files, so I opted for MPL 2.0 for now. Either way, it's open, demands changes by others to be shared, but allows others to use it as they'd like without compromising their own original, unrelated contributions, just as GNG demands. Anyhow, to advert a little more plainly, the Minimally Viable Embeddable Datastore in C# (MVED#) or, as I called it as I developed it (since I wasn't worried a whit about performance), Moore's Database, can be found here: https://github.com/ruffin--/mved/ It's not feature complete yet -- I'd like to sneak an UPDATE command handler in there before I do too much clean-up of existing code, which will be an easy refactor and then edit of the SELECT code -- but it's surprisingly close for what I think I'd like to use it for. A quick class for testing should follow UPDATE. The code is hilariously simple. Optimizations are almost non-existent. Yet, at the same time, I think it's a horribly accessible codebase. We'll see. I'm going to use it. It works just as well on OS X as Windows, and that's a great start for my apps that need an embedded database solution. I can only assume Xamarin's going to make it pretty easy to use MVED# on Andriod and iOS too. But okay, fine. I hear what you're thinking. If I have 121 commits and each one is, say, 30-45 minutes (let's go on the high side of that range and say 45 min, though admittedly I wonder how good of an estimate that is), that's 90 hours I didn't spend writing The Next Great Piece of Software with an existing engine. And it's not like I'm done yet. To me, that sort of cuts both ways. I'm surprised I'll be able to get a first functioning database engine in well less than three full-time weeks' of work, and I wonder if I'd waste that much time trying to get existing DBMSes working crossplatform. But then if I'd kept development to a primary platform and used the obvious DBMS engine for it, that's ~90 hours of work and months of free time I'd be ahead of where I am now to release an app for someone. Regardless, it's been, and hopefully will continue to be, a fun project. Happy hacking. Labels: coding, F/free, github, gng, mved, open, SqlDbSharp posted by ruffin at 11/02/2013 10:56:00 PM
0 comments
Don't commit your .suo file suo file, what is this ?: NO, do not add it to your CM system. The .suo files contain user dependant information, like the state of the solution explorer (collaps all nodes, close the solution, delete the file and you'll notice that the nodes in the solution explorer are expanded again). More than that, if you keep your files in your Document's folder on Windows, it's got your login name in it as well. /sigh Labels: noteToSelf, visual studio posted by ruffin at 11/02/2013 08:41:00 PM
0 comments
Friday, November 01, 2013
That Windows hex editor whose name I forget. Be.HexEditor (.NET C# hex edit control) \| Free Development software downloads at SourceForge.net Thanks, me. - Me. Labels: noteToSelf posted by ruffin at 11/01/2013 08:00:00 AM
0 comments