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

I'm going out of my mind with stuff to do, which usually means I take on yet another project, if only to make sure I take a little time for myself.

This time, that's a personal budgeting application made in RealBasic, and boy, does RealBasic have some pokey edges. One is the way that you can extend UI objects. It's insane. You can't make up your own object type, like in Java where MyFancyFrame might extend JFrame and provide a few new methods. Instead, you can extend the objects by creating new methods that act like the belong to the UI object from the start, but, and this is the important part, you can't actually put the methods on the UI objects themselves.

Instead, you have to declare the methods in a stand-alone module and ensure that the first parameter is the type of object that it should act, but only act, like it's attached to. So if I want to override the way a cell's rendered in a Listbox (as partially described in this thread and this thread before it, I have to create a module -- let's call it mdlExtensions -- insert the method I want to tack onto the Listbox -- we'll call that PopUpCellChoices -- and have a line like this for params:

extends lb As Listbox, row As Integer, column As Integer, astrChoices() As String

When I actually call the method, which is, again, sitting in its own module, as I might from my Listbox's CellClick event handler, I do it like this:

bOut = me.PopUpCellChoices(row, column, astrChoices)

That's right... it's not mdlExtensions.PopUpCellChoices, but Me., though the method is nowhere near me. In that method, however, "Me" is gone. It's all lb. All I did was obfuscate that I sent "Me" in as lb the Listbox.

Why don't I just call mdlExtensions.PopUpCellChoices(Me, row, column, astrChoices) I have no idea.

In other news, RealBasic's POP3Socket's MIME parsing ability is exactly zero when it comes to UTF-8, which sorta stink0rz. Still, I think I'll shell out for the Personal edition this time. I've been testing RealBasic for years, since OS 9 (maybe before?), and there really isn't any way to create a crossplatform codebase that acts native and has an embedded, SQL-literate database as quickly. Java's great, but I've finally given up on its being a good way to make a app for the masses. RealBasic can apparently even make it to the Mac App Store, so I think I'm going to code up one The Wrong Way (not ugly, just not up to my normal standards of overengineering) and see how difficult it'll be to publish.

Should be [mostly] fun, anyhow.

Labels: apple, java, rdbms, realbasic, shareware

I just downloaded the iTunes beta with iCloud, and my protected AAC files aren't there. Look, I understand that they're stuck saying that, "Previous purchases may be unavailable if they are no longer in the iTunes Store, App Store, or iBookstore," but Between the Buttons by the Rolling Stones is still on iTunes. I can't help myself. I have to ask. Why are the Stones off of my iCloud?

I think the answer is that I bought the album while it was a protected AAC. None of the tracks I've purchased via iTunes when it sold tracks with DRM are there. Unfortunately, the Stones aren't on the iTunes Plus upgrade list, so I'm toast.

I'm a little miffed that things I bought from Apple aren't on my iCloud, even though Apple told me the tracks should be, since they're still in the iTunes Music Store library. And don't think Apple doesn't have a stake in making Protected AAC disappear. They'd love to stop validating owners. Lost another Protected AAC? It's gone forever.

Thus is licensing, I suppose, and I can always burn my 128 kbps Protected AACs to CD and rip them back as mp3. It's nice to have my other files, some I didn't even know I was missing, back. Apple is, admittedly, bringing your iTunes Plus files without DRM back from the dead if they've been lost. Amazon isn't doing that with their cloud-player; only new files get saved. And admittedly, most of my tracks are from CDs or Furthurnet.org and other [legal] live show trading sources.

It's always been a real pain to sync libraries between computers, much less portable devices. For $30 a year, now with iTunes Match, Apple will do all of the heavy lifting for you. For $30, I can take those 128 Protected AACs from (CD to crappy) mp3s on to 256 kbps AAC -- and all of the rest of my mp3s -- without DRM.

In fact, that's power-play number two here: Move everyone's library from the standard of mp3 to AAC, and push AAC's adoption. My Android phone already plays AAC, and with moves like this, nobody will be able to drop it. Imagine the amount of de facto conversions from mp3 to AAC iTunes Match will bring. (Nevermind that I recently swapped to 320 kbps for mp3 rips... not that it apparently makes much difference in all but the most technical tracks.)

That is, Apple'll do all the file syncing heavy lifting except in a few cases where you played early adopter, went out on a limb, and bought files from Apple. Thanks, Steve. Thanks for telling me to get your own files off of your cloud.

Labels: DRM, iTunes

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!

Thursday, June 30, 2011
Why Apple should support Linux-only users It's not necessarily intuitive, but after reading this blog post called Installing Linux on a MacBook without OS X, I think you have to concede the guy makes a lot of sense: [To Apple:] Help the Linux people write proper ELI drivers for your machines, if you are serious about this. I understand you don’t want OS X running on normal PC’s. You are using OS X as an argument for buying your hardware. If you sold OS X separately your machines would be cheaper and your upgrades more expensive, and that would probably not be good for business. But making it hard to run OTHER things on Macs doesn’t make any sense. [emph mine] Sure, there's a good reason for Apple to want you to use OS X as you primary OS that the blogger here chooses to overlook, namely that if you use OS X now, you're more likely to buy OS X again. And sure enough, this guy ends with... "All in all, I can not recommend you to buy MacBooks unless you intend your main OS to be OS X. And I can’t recommend OS X to a developer. Yes, this buy was a mistake." That's serious overkill, and obviously is coming from a guy who does Linux/OSS development, but it doesn't negate his initial, clever argument. If I am already a Linux-phile and Apple's primarily in the hardware business, which I argue they are, why not make your hardware open to whoever wants to use it? Sure, keep OS X exclusive to Mac hardware, but when you've got guys going out of their way to buy your hardware for Linux, build in at least enough support that it's a painless install, just as you do for a more conventional competitor, Microsoft Windows. I think you can use Boot Camp to install Windows and then blast OS X away. Labels: apple, linux, os x posted by ruffin at 6/30/2011 09:02:00 PM
0 comments
Thursday, June 23, 2011
PHP PDO, Drupal, and platform lock-in General concepts \| drupal.org: The Drupal database layer is built atop PHP's PDO library. PDO provides a unified, object-oriented API for accessing different databases but it does not provide an abstraction for the different dialects of SQL used by different databases. I believe the implication is that Drupal has those drivers to attach to multiple SQL rdbms. Look, hiding the SQL is all well and good, but what you really end up with isn't a savings. It's platform lock-in. If I know Drupal's flavor of PDO, I can't do anything with an ANSI SQL compliant rdbms in Java. I can't do it with VB.NET/ADO.NET. I can't do it with RealBasic's crazy database features. I only know PDO. If I already knew ANSI SQL, I have to learn a whole new language, not just a dialect. I've SQuirreL-SQL'd my way from MS SQL Server to Jet to Postgres to MySQL to Oracle to Sybase to Derby to... you get the point. There are minor flavor changes from one rdbms to another, but nothing, nothing as involved as learning this PDO crap. There's really only one place an abstraction layer like this makes sense, and that's if you're looking to move to another rdbms. Perhaps many develop on AMP and move to MS SQL or Oracle, but I kind of doubt it. If you've normalized [your code] well, even that's not that big a task. There are too many SQL abstraction layers out there when you really should just learn SQL. Instead of marrying yourself to a single MVC platform, you'll be ready to do your thing anywhere and in any language. This is why the guy who taught me to be a dba always said to stick as much logic as you can into the database where it belongs. I don't think we'll see many cursors or triggers or, most importantly, sprocs with either or both in PDO. Put your logic in the database system that's not going to change, and move from Drupal to Joolma to roll-your-own as quickly as possible. Save your data, not your interface. (Now, I understand. They want you to use Drupal, not rdbms X. They want every Drupal module to work with every combo of available platforms. I get it. It's a mistake. ;^D) You're always picking a platform when you code. Make sure you lock-in intelligently. (Although the more I look at this, the greater the possibility that they may be working on doing just that with PDO. Still, any time you have to learn a new OM to hit a database, you've wasted a developer's time.) Labels: Drupal, rdbms posted by ruffin at 6/23/2011 02:48:00 PM
0 comments
Wednesday, June 22, 2011
RealBasic Extends -- Hello, kludgey I'm going out of my mind with stuff to do, which usually means I take on yet another project, if only to make sure I take a little time for myself. This time, that's a personal budgeting application made in RealBasic, and boy, does RealBasic have some pokey edges. One is the way that you can extend UI objects. It's insane. You can't make up your own object type, like in Java where MyFancyFrame might extend JFrame and provide a few new methods. Instead, you can extend the objects by creating new methods that act like the belong to the UI object from the start, but, and this is the important part, you can't actually put the methods on the UI objects themselves. Instead, you have to declare the methods in a stand-alone module and ensure that the first parameter is the type of object that it should act, but only act, like it's attached to. So if I want to override the way a cell's rendered in a Listbox (as partially described in this thread and this thread before it, I have to create a module -- let's call it mdlExtensions -- insert the method I want to tack onto the Listbox -- we'll call that PopUpCellChoices -- and have a line like this for params: `extends lb As Listbox, row As Integer, column As Integer, astrChoices() As String` When I actually call the method, which is, again, sitting in its own module, as I might from my Listbox's CellClick event handler, I do it like this: `bOut = me.PopUpCellChoices(row, column, astrChoices)` That's right... it's not mdlExtensions.PopUpCellChoices, but Me., though the method is nowhere near me. In that method, however, "Me" is gone. It's all lb. All I did was obfuscate that I sent "Me" in as lb the Listbox. Why don't I just call `mdlExtensions.PopUpCellChoices(Me, row, column, astrChoices)` I have no idea. In other news, RealBasic's POP3Socket's MIME parsing ability is exactly zero when it comes to UTF-8, which sorta stink0rz. Still, I think I'll shell out for the Personal edition this time. I've been testing RealBasic for years, since OS 9 (maybe before?), and there really isn't any way to create a crossplatform codebase that acts native and has an embedded, SQL-literate database as quickly. Java's great, but I've finally given up on its being a good way to make a app for the masses. RealBasic can apparently even make it to the Mac App Store, so I think I'm going to code up one The Wrong Way (not ugly, just not up to my normal standards of overengineering) and see how difficult it'll be to publish. Should be [mostly] fun, anyhow. Labels: apple, java, rdbms, realbasic, shareware posted by ruffin at 6/22/2011 04:29:00 PM
0 comments
Tuesday, June 14, 2011
Learning about "Thunderbird: the global picture" Talk about giving back... This is an impressive series of blog posts: I've been working on Thunderbird Conversations for more than a year now, and I've learned a lot about Thunderbird internals over the past months. I thought I'd share some thoughts on the design of Thunderbird Conversations, in the hope that it helps would-be extension authors better grasp the design and the relationship between Gloda, libmime, the message headers, and the message database. This is the first blog post in a series. In this post, I'll talk how various parts of Thunderbird interact together. In another post, I'll talk about the Thunderbird Conversations design. Interesting info follows. posted by ruffin at 6/14/2011 10:14:00 PM
0 comments
Monday, June 13, 2011
First Doonesbury Flag Burning Amendment Cartoon: November 05, 1989 Note to self: Doonesbury Comic Strip, November 05, 1989 on GoComics.com posted by ruffin at 6/13/2011 09:06:00 PM
0 comments
Hello, Mr. Gladwell: "50% of iPhones Brought to Genius Bar Have Never Been Synced" From Macrumors. This is kinda hard to believe, while not, all at the same time: Fifty percent of iPhone owners who have iPhones swapped at the Genius Bar have never plugged them into a computer to backup or sync If you didn't believe Joel Spolsky's Strategy Letter III before, you should now. This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you'll double your sales again. Now interestingly, if you're still in the lead, a single barrier doesn't necessarily kill you like Spolsky thought it might. And, of course, iPhones don't, I assume, make up a majority of the iPods out there. Makes you wonder how many iPod touch users synced, or if they just bought music via WiFi. To take over a market, you have to address every barrier to entry. If you forget just one barrier which trips up 50% of your potential customers, then by definition, you can't have more than 50% market share, and you will never displace the dominant player, and you'll be stuck on the sad (omelet) side of chicken and egg problems. Will iCloud mean more iTMS purchases? No idea. I don't sync up my Android phone much, and kinda like leaving the tether behind. It's not like the iPhone had to be synced to buy apps or music. It's really just a backup issue, right? Still, Apple screwed up there. Who knew? Labels: iphone posted by ruffin at 6/13/2011 05:18:00 PM
0 comments
Wednesday, June 08, 2011
Hello Chrome 12, good-bye Google Gears \| The Download Blog - Download.com Hello Chrome 12, good-bye Google Gears \| The Download Blog - Download.com: Hello Chrome 12, good-bye Google Gears That didn't take long. posted by ruffin at 6/08/2011 07:33:00 PM
0 comments
Tuesday, June 07, 2011
Jobs tells me to get off of his iCloud -- Apple Blocks Protected AAC? I just downloaded the iTunes beta with iCloud, and my protected AAC files aren't there. Look, I understand that they're stuck saying that, "Previous purchases may be unavailable if they are no longer in the iTunes Store, App Store, or iBookstore," but Between the Buttons by the Rolling Stones is still on iTunes. I can't help myself. I have to ask. Why are the Stones off of my iCloud? I think the answer is that I bought the album while it was a protected AAC. None of the tracks I've purchased via iTunes when it sold tracks with DRM are there. Unfortunately, the Stones aren't on the iTunes Plus upgrade list, so I'm toast. I'm a little miffed that things I bought from Apple aren't on my iCloud, even though Apple told me the tracks should be, since they're still in the iTunes Music Store library. And don't think Apple doesn't have a stake in making Protected AAC disappear. They'd love to stop validating owners. Lost another Protected AAC? It's gone forever. Thus is licensing, I suppose, and I can always burn my 128 kbps Protected AACs to CD and rip them back as mp3. It's nice to have my other files, some I didn't even know I was missing, back. Apple is, admittedly, bringing your iTunes Plus files without DRM back from the dead if they've been lost. Amazon isn't doing that with their cloud-player; only new files get saved. And admittedly, most of my tracks are from CDs or Furthurnet.org and other [legal] live show trading sources. It's always been a real pain to sync libraries between computers, much less portable devices. For $30 a year, now with iTunes Match, Apple will do all of the heavy lifting for you. For $30, I can take those 128 Protected AACs from (CD to crappy) mp3s on to 256 kbps AAC -- and all of the rest of my mp3s -- without DRM. In fact, that's power-play number two here: Move everyone's library from the standard of mp3 to AAC, and push AAC's adoption. My Android phone already plays AAC, and with moves like this, nobody will be able to drop it. Imagine the amount of de facto conversions from mp3 to AAC iTunes Match will bring. (Nevermind that I recently swapped to 320 kbps for mp3 rips... not that it apparently makes much difference in all but the most technical tracks.) That is, Apple'll do all the file syncing heavy lifting except in a few cases where you played early adopter, went out on a limb, and bought files from Apple. Thanks, Steve. Thanks for telling me to get your own files off of your cloud. Labels: DRM, iTunes posted by ruffin at 6/07/2011 10:53:00 AM
0 comments
Sunday, June 05, 2011
Note to Self: newlines - Join lines inside paragraphs in vim - Super User newlines - Join lines inside paragraphs in vim - Super User: This should do it: :set tw=99999 gggqG tw is set to some value at least as large as the number of characters in the longest paragraph. gg moves the cursor to the first line; gq is the command to reformat; G moves the cursor to the last line, telling gq to reformat from the current cursor location to the last line. Seems to work. So to save paper, I'm taking an article from Firefox, saving as text, pulling out the line breaks with VIm, then printing from Word with very little margins. Worth it? Doanno. Works though. Labels: problem solved posted by ruffin at 6/05/2011 01:59:00 PM
0 comments
Cell Phones -- Our Generation's Cigarettes Cellphones and Cancer - A Far-From-Settled Issue - NYTimes.com: The warnings may be missed by an awful lot of customers. The United States has 292 million wireless numbers in use, approaching one for every adult and child, according to C.T.I.A.-The Wireless Association, the cellphone industry’s primary trade group. It says that as of June, about a quarter of domestic households were wireless-only. If health issues arise from ordinary use of this hardware, it would affect not just many customers but also a huge industry. Our voice calls — we chat on our cellphones 2.26 trillion minutes annually, according to the C.T.I.A. — generate $109 billion for the wireless carriers. The worst part is that they don't even keep us thin. posted by ruffin at 6/05/2011 01:01:00 PM
0 comments
Saturday, June 04, 2011
vWorker/Rent-a-Coder understands scoping bets? I got a real kick out of vWorker's explanation why programmers underbid for projects. They do miss one thing, which I'll add below. You may be thinking this is a great thing for you, because it saves you money. However, if you think about it, receiving a severely under-market bid really doesn't. Imagine you are a worker who won a project and began work. Then, reality begins to sink in as you realize you under-bid by a factor between two and five. Soon you're calculating what that means. You've just taken a 50-80% pay-cut, and found yourself obligated to work for a period that's two to five times longer than you expected. How would you perform? You would probably not be delivering your best work. You might become very difficult to deal with. And you might even throw up your hands and completely quit. This is what tends to happen on larger pay-for-deliverables projects. You might be thinking 'So what? It's their own fault for bidding too low. I don't care because I still get my money back with the triple-point guarantee'. Yes, it's true you will get your money back. However, you'll have wasted all the time spent qualifying workers and interviewing, and will be stuck with the hassle of starting all over again. And even after your repost, re-qualify workers, and redo the work process, you still have the exact same 25% chance of ending up in the same place again. The real reason this happens is the above, sure, but also 1.) Lots of programmers are dolts who can't do what they think they can. ("Sure, I can give you a CMS and online marketplace in 20 hours! I've got this great third-party, open-source package that I Googled up!") and 2.) Those that are good want to get the project and bid based on their Best Case Scenario. You know, the one where the coding breaks like you want it to: You'll have tunes blasting out of your earphones, you'll forget about your coffee, and you'll figure out some way to factor your code where all you need are a few variations on three quick, brilliantly-written functions. That actually happens, what, 20% of the time? Just enough that you think it'll happen every time you decide it should happen. But the devil's always in the details. Unless things break perfectly, you spend 35% of your time doing the last 15% of the work. posted by ruffin at 6/04/2011 10:09:00 AM
0 comments
Wednesday, June 01, 2011
Chrome's javascript debugger rocks I'm not sure why I feel this way, but it does. It seems to present errors in an easy, human-readable fashion, and its ability to jump into code is awesome. The way it reloads from scratch when you reload a page is also nice. I'm partial to having it in its own window, but it's nice. It's like a built-in, well polished Venkman. I've taken to debugging my code on Chrome first. Labels: chrome, code, javascript posted by ruffin at 6/01/2011 04:57:00 PM
0 comments