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. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green. |
|
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...
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! |
|
Tuesday, June 25, 2002 | |
The MS ASP.NET Web Matrix app does things quite a bit differently than Visual Studio.NET. The Matrix seems to be a little more along the lines of what old-timer ASP 3 programmers expect. I jumped right in and turned off option explicit and turned vb strict to false and started inline coding with poor case and without dim statements. Woohoo! Of course the devil's in the details. I tried to take some of the code I'd Matrixed (where they got that name, I'm not sure) and push it into VS.NET. Nothing. My DataGrid code I'd added in the Matrix was going nowhere. Here's the rub -- from MS's .NET help (found here if you're on Windows and have .NET installed). Alternatively, the ASP.NET page framework also supports an automatic way to associate page events and methods. If the AutoEventWireup attribute of the Page directive is set to true (or if it is missing, since by default it is true), the page framework calls page events automatically, specifically the Page_Init and Page_Load methods. In that case, no explicit Handles clause or delegate is needed. The disadvantage of the AutoEventWireup attribute is that it requires that the page event handlers have specific, predictable names. This limits your flexibility in how you name your event handlers. Therefore, in Visual Studio, the AutoEventWireup attribute is set to false by default and the designer generates explicit code to bind page events to methods. If you do set AutoEventWireup to true, Visual Studio will generate code to bind the events and the page framework will automatically call events based on their names. This can result in the same event code being called twice when the page runs. As a consequence, you should always leave AutoEventWireup set to false when working in Visual Studio. If you use VB 6 (where I do use Option Explicit so as not to drive myself mad -- ASP means all the code is [more or less] on the same page; VB 6 is another story), you're used to wacky names for subs like "cmdSmack_Click()" to handle, in this case, button click events. If you came to VB from Java, you wondered how in the world VB knew to call that sub when cmdSmack was clicked without any code to link the two; there was no "ActionListener" or anything of the sort. Wow! A whole layer of overhead just disappeared! Of course changing the sub's name breaks things. And, quite strangely, adding a sub named "cmdSmack_Click" by hand "out of the blue" still makes that code happen when you click the button. Where's the glue? Holding the event handler to the sub? There is no glue in VB 6 (or rather, the glue's always there, just invisible), and there's no glue in an ASP.NET page made by VS.NET by default. But if you set AutoEventWireup to true in your asp.net page in VS.NET, all you have to do is write a sub "Page_Load(Source As Object, E As EventArgs)" and your code is executed with each load. In the Matrix, wireup's going to happen by default. Just to say that comparing the two IDEs makes it clear that Microsoft has a couple of different camps as to what's the "right" way to code files. Or, at the very least, they recognize there are at least two camps on how to do things right in the world of ASP.NET programmers. Big shops use VS.NET and separate GUI from logic and can utilize a more robust language like C#, small timers can get back to quick scripting like they're used to doing with the Matrix, vb.net, and a few hard-line compatibilities turned off. posted by ruffin at 6/25/2002 05:12:00 PM |
|
Finally getting some time to study XML in VB 6 and ASP 3.0 at work, and I'm hoping to replace some code that's been writing to a, urm, "homebrew formatted" text file in the meanwhile. One of the scary ASPfriends listservs, review-tools, had a member ask for xml editing tool recommendations yesterday. With three votes in, the current winner is XML Spy. Screengrabs of the editor in action are hard/impossible to quickly find on the site, so I surfed over to a review of a recent version of XML Spy at PC Magazine. Here's a quote: Loaded with tools, wizards, inspectors, and editors, XML Spy 4.3 is a true IDE. When you launch the program, no fewer than six windows pop up... This concerns me. I'm admittedly a newbie to the intricacies of XML, but what's there to IDE [I mean "IDE" in the sense of "verbing weirds language"]? And why are six windows such an inherently good thing? I realize XSL and XPath and friends are a little esoteric when you're not coming from a regexp background, but a six window IDE? The whole point of XML, as I understand it -- and believe it should be, is that we finally have a standard means of pushing zeroes and ones that are not only easily read by a machine, but also by humans! An XML editor shouldn't have six windows. The editor should simply have some shortcuts to put the tags around the content. You shouldn't have to type every key when those keys can be easily and accurately anticipated. At the same time, you shouldn't need tons of overhead to read and understand your XML file. I've never quite understood the whole XML "esoteria" business. Why we don't just use ANSI-92 SQL to access XML files is entirely beyond me. Guess I should finish reading the review and start learning some "esoteria" before I stick ye olde foote in ye olde mouthe. posted by ruffin at 6/25/2002 10:04:00 AM |
|
Friday, June 21, 2002 | |
The last few blogs have been too long. Read the article titled Polyglot Programming and be impressed with the following quote: The signal to C++ developers is hard to miss: The .NET designers don't think too highly of the C++ object model and expect you to move to the modern world as they see it. The role of Unmanaged C++ is simply to smooth the transition by allowing C++ developers to move an application to the managed side one class at a time. It's interesting what 20 megs will get you. posted by ruffin at 6/21/2002 11:02:00 AM |
|
Thursday, June 20, 2002 | |
All the important bloggers already slammed Joel on Software's take on the .NET languages, so I thought I'd join in to pretend I was all "insider mainstream". Here's the offending quote: But I hardly ever choose a language based on syntax. Yeah, I prefer the {}; languages (C/C++/C#/Java). And I have lots of opinions as to what makes a "good" syntax. But I wouldn't accept a 20 MB runtime just to get semicolons. And here's why that's bad, again a quote: But how do I develop a UNIX command line utility in .NET? How do I develop a tiny Windows EXE in less than 16K in .NET? I really don't give a rip about the first quote. There he's missing the point... He likes VB 6 now, whines a touch about the vb runtime that's required, but realizes that 2 meg or so runtime isn't a big deal anymore because 2 megs isn't a big deal for anyone with any sort of net access. It's also nuttin' now because newer versions of Windows come with the runtime installed! The .NET runtime's no different, and 20 megs in 2002 isn't close to 2 megs in 1997. The second point I just don't get. You wanna write something that's 16k? Everyone knows if you want a 16k game you're going to have to use bankswitching! (For those thankfully not geeky enough to know and too lazy to click, bankswitching is how you access more than 4k of ROM in an Atari 2600 game) There's no reason to make a 16k command line app any more unless it's just to show off -- or to program for art's sake (again, see bankswitching), not for practical reasons. I suppose he's exaggerating and means he'd like to program an app that's floppy sized, let's say. Then the answer's simple -- If you're targetting Windows 98 and NT, well, you're up the creek, har har. Don't use .NET. Don't even use VB. Use ANSI C and enjoy. That was simple, wasn't it? posted by ruffin at 6/20/2002 03:48:00 PM |
|
Wednesday, June 19, 2002 | |
I'm not the only one that's used "The first hit of heroin is always free," to describe Microsoft's decision to freely distribute the .NET runtime and SDK. Obviously I stole that quote from Scott McNealy of Sun. But I'm beginning to wonder if this first hit isn't enough (as in, "we don't need more dope".). Until VB.NET, pretty much all your VB code, version one through six, would work in any version higher than the one you originally used. It was backwards compatibilty at its most extreme. Additionally, even moreso than Apple with OS X (that bent over backwards including the "Classic" compatibility layer), Windows versions have always gone out of their way to keep that old app working. I can still run some of my favorite DOS apps on Windows 2000 (admittedly two games), and there's nothing stopping most, say, VB 4.0 apps from running on Windows XP. I can't imagine Microsoft is going to break compatiblity with .NET 1.0 with a future release of the runtime.* I have to think anything that comes out of the .NET 1.0 SDK is going to work for years to come. .NET 2.0 might have a ton of bugfixes and 2.0 might very well cost some cash, but the cat's out of the bag. The price of entry into .NET programming is the price of Windows XP, and it's not getting any higher anytime soon. With IDEs like SharpDevelop for C# (of course the site's down right now) and now the ASP.NET Web Matrix from Microsoft as a free, floppy-sized download for ASP.NET (VB.NET or C#), there's no reason anyone who has paid their entrance fee to Windows not to start learning some .NET. * Quite naturally, I could be wrong. Just doesn't seem like they would. posted by ruffin at 6/19/2002 09:37:00 AM |
|
Tuesday, June 18, 2002 | |
Quick blog: Just so I'll remember to talk about it later, note to self: I'm pretty sure X11 & friends is going to ultimately do what Sun wishes Java would. I'm already spoiled expecting to find vi or vim on any machine I use, Solaris, Mac OS X or 9-, or Windows. Eclipse is another (not X11, sure, but isn't Sun's Java; that's IBM's, so to speak). If I could expect to find applications as similar crossplatform as vi[m], Gimp, and AbiWord are, I know I'd start using those like I do the three I just listed. Sure, the crossplatform user isn't exactly common, but at least Window's Office practical-monopoly could start to fall. People would start choosing computer operating systems like they do gaming consoles, "What're this console's exclusives?" As Joel would probably say, X11 makes traditional office applications a commodity (free for the user once the society gets used to the Free software's in's and out's). Now you'll buy your OS not for Office (or what-have-you), but for things like iDVD or Internet Explorer or someone's business server suite. posted by ruffin at 6/18/2002 12:33:00 PM |
|
When last we left our hero as he was getting to know REALbasic, he was whining about a number of REALbasic's shortcomings. I'm not going to claim REALbasic doesn't have these shortcomings, but after a few more nights of play and some help from the kind folk at the REALbasic listserver, things aren't quite so ugly as they first were. REALbasic is still missing several key features that it needs before I can call it "mature", but I've nearly solved two main hurdles. First, lacking string functions -- For heaven's sake, man, just create a module called mdlVBcompat or something similar. I've done that and started up some replacement subs and functions. Unfortunately REALbasic doesn't seem to let you return arrays from functions, so I'm having to work on parameters "ByRef", so to speak, for things like the Split() function. Either way, creating reusable code, even if I have to drag and drop into new apps, is an okay fix. The constant "vbNewLine" (a new line, no less) was a particularly tough cookie, as the GUI that allows you to define constants (that's right -- it's a GUI that makes code; you can't write code directly when defining constants) only has a single line for your constant value. Nor does it accept "\n" or Chr(13) or the like. Rather, it does accept them, but reads them literally, not as a new line. The trick was to (again, thanks to the REALbasic list, this time the archives) get a newline in BBEdit Lite and *paste* the danged thing into the REALbasic GUI. Voila. Instant newline. Haven't checked to see if that works xplat (or even on OS 9), but if it doesn't I'll just throw in some more Consts (since I can't #ifdef constants through the GUI *sigh*) Finally there's the slowly rendering textbox. This is a problem, sure enough. The textbox on REALbasic isn't as good as the one in Visual Basic. It's much slower and is in need of quite a bit of optimization (which, from what I gather, it's getting). Luckily what I was trying to do shouldn't ever feel this issue. My code was whacked. Here's analogous code in VB:
So I was rewriting the string 300 times instead of appending. Idiot. Though my backwards way of doing things shouldn't crash the app, and still performs acceptably quickly in VB, performance is improved quite a bit once I have my head on straight. In sum, though REALbasic doesn't score any maturity points with its Textbox in OS X, neither did my programming skillz. :^D posted by ruffin at 6/18/2002 09:28:00 AM |
|
Monday, June 17, 2002 | |
Wow. if this ASP.NET Web Matrix Project does half of what it claims to do, Microsoft's stock has risen quite a bit in my eyes. For example: How big is the ASP.NET Web Matrix download? The ASP.NET Web Matrix download is about 1.2Mb and expands to 2.5Mb when installed on your computer. Download and installation takes less than 5 minutes on a 56k dialup modem. Do I need an IIS Web Server to develop web applications using ASP.NET Web Matrix? No. ASP.NET Web Matrix does not require IIS on a machine for development. ASP.NET Web Matrix includes its own mini-webserver that hosts ASP.NET and can be used for local machine development and testing ... and get this... What is the price for ASP.NET Web Matrix? ASP.NET Web Matrix is completely free. Wow. All it's really missing is, "* Intellisence statement completion support", which, though huge, still makes this an impressive product. Small, "debugging version" of IIS and SQL server, fits on a floppy, and runs on XP home. That's about the last reason I wouldn't want an XP box moved right out of the way. Wonder how the whole, "First hit of heroin is always free," bit will translate here. This is "a technology preview", whatever that's going to mean. Wonder how this will mesh with SharpDevelop? posted by ruffin at 6/17/2002 05:52:00 PM |
|
It hits me that Apple's idea of calling the newest version of its operating system "OS X" at the same time they hit version 10.0 overall doesn't scale very well. What happens when they eventually go to version 11.0? Do they use OS XI? That seems a little silly. Do they keep it OS X though it's now version 11? How do you now pronounce "OS X" anyhow? This is even worse than having MRJ's version number on OS 9- (MRJ is Apple's Java virtual machine) have absolutely nothing to do with the version of Java it represents. MRJ 2.2 is not Java 2; it's actually Java 1.1.8 (or maybe even 1.1.7). Course Java 1.2 is called the "Java 2" platform -- as is Java 1.3 and 1.4, so Sun's not much better. Then of course there's Windows 2000, which tells you on each boot up that it's based on Windows NT technology. Course NT means "New Technology", so I'm not sure where that's going (Win2k is based on ["old and proven'] New Technology technology) -- and Win2k isn't related to Win98, but WinME is based on Win98 -- but in its turn doesn't share a kernel with WinXP, another Windows version with two letters instead of approximate years. And Win98SE? You'd think we'd ordered a custom-built car from the factory. And don't get me started on ASP's relation to ASP.NET. Suffice it to say that ASP stands for "Active Server Pages" in one acronym and apparently stands for *nothing* in the other, if you believe all Microsoft tells you. And then there's the whole Visual J++ 3.0 (?) to 6.0 jump before its switch to Visual J#. Is there something about Java that makes things hard to name? It's all horribly confusing. posted by ruffin at 6/17/2002 04:03:00 PM |
|
Sunday, June 16, 2002 | |
In other grand news, now that I've very nearly got a good Quake 1 server browser done in REALbasic for Mac OS X mainly because there's no GameRanger for OS X (and there hasn't been any word nearly a year(?)), GameRanger for OS X is announced. If I'd been on top of things Thursday I guess I woulda seen it, but doesn't it just figure? (for those of you not in the know, I released the first Quake 2 server browser for the Mac years ago -- but as soon as I got out a shoddy version 1.0 GameRanger was released (not four hours later) and I was squashed. Looks like I'm a day or two late and a few dollars short yet again! Sheesh.) posted by ruffin at 6/16/2002 11:40:00 PM |
|
Though I've ended up spending more time this weekend reading than coding, I've done enough with REALbasic to know it's not nearly as mature as Visual Basic is on Windows. Of course this is no surprise. Microsoft has a larger budget, related projects that can share components and development (eg, in VB 6.0, VB apparently share VC++ 6.0's compiler), VB's been around for many more years, and, of course, more users depend on VB for mission-critical applications. It's worse than David vs. Goliath. But the reasons don't matter when you're a coder. Right now Apple's Java implementation is head and shoulders above REALbasic when it comes to maturity (of course Apple works with Sun to make sure it's all up to spec, but that's another story). REALbasic simply leaves me feeling a little put out. Here are a few examples: How to use arrays of dynamically changing size (from the built-in docs): If you're using 3.0 or later, dim the array for -1 elements. You can then grow the array dynamically with gHeadingNames.Append or .Insert(arrayPos As Integer) method of the array. To me that sounds like a hack. Some of the example code (in this case for opening a file): Dim folder, file As FolderItem To me, that snippet is less than impressive. "fileReadFrom"? "path"? Not exactly the best var names. When you give users sample code, remember that it's going to be used word-for-word by more programmers than you can count. Make sure it's the best (VB isn't always perfect on this one, either, of course) There are also fewer built-in functions than I'd expect. Very few string manipulation functions, for example -- it's missing a Split(strToSplit, strDelimiter) function, for example. It wouldn't be hard to add that to REALbasic's default toolbox. And adding a function like this manually to each project isn't very easy either... Each object has its own little layout treeview with a spot separate from Control event handlers for your methods, and each method is essentially stored in its own file. Neither does the IDE in OS X allow you to have two projects open at once. These two together makes it hard to cut and paste (aka, "share") code.* REALbasic also has some trouble in OS X with what seem like very simple tasks. I tried a simple for loop, i = 1 to 300, with each time through adding one line to an EditField (the VB "RichTextBox" and "textBox" equivalent in one). After about 30 iterations it would take a second or two to add each line, and the app was taking over 60% of my processor and 60+ megs of RAM (according to the "top" command)!!! This was a test program to check and see what was causing horrible performance in the app I was writing, and I was somewhat relieved to see that it wasn't the Shell object's fault. At the same time I was a little scared to see simple GUIs take up 60 megs of RAM. I've since found a workaround (simple enough -- only refreshing the GUI after every 30 lines or so seems to make the app happy), but this just isn't a good sign. Perhaps I'm a little too picky, and I could most certainly be missing some settings in the IDE -- I am a newbie after all. For instance, back up at (*), I'm pretty sure I can use some drag and drop to make a reusuable module sit on my desktop that I can then drag and drop into other projects. But to a coder who likes vim, this isn't exactly the best solution. Just b/c Mac apps generally have a very advanced GUI for the one-button mouse users doesn't mean that's best for its programmers (or is it?). REALbasic is certainly the Mac's answer to Visual Basic, it's nowhere near as mature a technology, I'm afraid. Hopefully I'll have a solid block of time to play with it more in the near future (as opposed to hacking on the couch while watching movies). posted by ruffin at 6/16/2002 11:17:00 PM |
|
Friday, June 14, 2002 | |
Once again proving how poorly I lurk on newsgroups, it didn't take me more than a few days to post to the REALbasic mailing list, before even finishing my first app using REALbasic (hopefully will have time this weekend). Got a few positive comments on the post, so I figured I'd do a quick copy & paste into ye ole blog. >OK, I've talked to some people about it, and decided that I should not >make a game that is just "easy," but also something I really wanna do. I'm about as new to REALbasic as it gets (though I've years of Visual Basic under my belt), but just fwiw let me warn against too ambitious an undertaking. Back in another life I set up a cross-assembly suite for the 6507 processor with MPW so that I could program Atari 2600 games [sic] on my StarMax 3000. I wanted to do a game like Jumpman for the Commodore 64, and had all sorts of fancy algorithms that helped me scrunch the most boards per 4kb cartridge, the highest resolution ("single scan line") possible, and the smartest AI the 2600 had ever seen. Though I got the board compression proof of concepted and built, let's just say the game never got done (partially to blame on getting a good day job and partially b/c I was shooting much too high/pie in the sky there). Furthermore, most of the games that do get done for the 2600 now-a-days are demos gone wild -- people started playing with the hardware and that eventually morphed into an original game. I've also enjoyed what I've seen of REALbasic so far (two nights of play with the 30-day trial) because it gets me a much more responsive GUI on OS X with about a tenth of the effort I was spending to build in Java. I'd love to get a "true cross-platform app" (incl Linux) with Java and have the programming "done right" (whatever that bias of mine means -- probably from too much VB codin'!), but it's probably much better in the long run to quickly get out a number apps that work instead of a very few that are "artful masterpieces" of code. So, short story long, start with something incredibly easy. Play with REALbasic and let your play morph into a game. You'll feel better having accomplished that game, and probably learned the skills you'll need to make your Diablo-like game all the more quickly for having the first game under your belt! Hey, who hasn't had a great time playing Stratega?!! Nothing to be ashamed of there, and probably a slightly easier undertaking overall. 2ยข posted by ruffin at 6/14/2002 12:02:00 AM |
|
Wednesday, June 12, 2002 | |
Another interesting article from Joel, this time about REALbasic. Seems Joel really likes REALbasic b/c RB's syntax is very close to Visual Basic on Windows -- he can *almost* see a future where you code a GUI in Visual Basic and have it, with a few minor UI tweaks to make the app look like a Mac user expects, compile into native Mac code with REALbasic. I alluded to the similarity yesterday -- RB seems to differ from VB sometimes just for the sake of being different. If RB had a "strict VB compatibility mode", perhaps you'd be better off. Behind these GUIs would be crossplatform C++ doing the heavy lifting. Fairly interesting article, but it left me with a few questions. * Does C++ give that much of an advantge behind the scenes because it doesn't garbage collect? Why not use Java for your xplat heavy lifting code? * What about COM makes it that much better than opening a pipe between the GUI and the engine? * How tough would it be now to write an RB to VB.NET converter? I've been wondering about that for a while (what, two days? :^D). Seems we're coming at a relatively similar question from not-so-similar directions. He's wanting to get VC++ & VB to run on Mac; I'm looking for a good xplat way to approach making good applications from any direction (ie, I'd be happy to use RB if it mean quicker apps). I think the reason there is simple -- he's probably got a few "man-years" in legacy code that uses VC++ and COM; I've got very few personal projects (I can count them on my left index finger) that I couldn't rewrite in a couple of days in whatever language. I think we both agree that Win + Mac == 99.994% of the desktop market. I don't know that kicking Linux to the curb for the purposes of this discussion is a bad idea for the time being (but that's next). posted by ruffin at 6/12/2002 02:52:00 PM |
|
Just a few minutes with REALbasic last night, and the proverbial lovefest continues (not as strong as the vim lovefest, mind you. I'm going to have to research the vim charity a little and see if they're on the up and up...). Yesterday's "breakthrough" was the interactive shell mode that apparently was added to the last version of REALbasic. Though this is basically just opening a pipe to the command line (only works in OS X and Windows), I had a spellchecker poc (of sorts) in just a few minutes using aspell which I'd installed on my iBook a few days ago with fink just for kicks. Why is this good? Well, now you can slap a REALbasic GUI over top of most any command line UNIX app (actually *any* app, but if it's got a GUI already...) in OS X and have it maintain state and resources very easily. Before (and the way it still is in VB 6.0, afaik), you just fired off a command line and read the reponse without maintaining any sort of connection. The Shell was a one-shot process. (Note: I'm sure there's some way of having a persistent shell in VB 6.0; it's all 0's & 1's, after all, and if you're willing to travel outside of traditional VB 6 coding (APIs, etc), I haven't found a thing you can't do in VB.) This also makes for very easy integration with xplat headless apps. So if I want to write something in Java and have a GUI in OS X, REALbasic once again comes to the rescue. An interactive shell is also the final thing I needed to do a Quake 1 server browser "the way I want to", so I suspect I'll be able to hack that up pretty quickly. And in fun "Link of the Day" news, my original Quake 2 server browser still has its site up at AOL. What a hack. No threading, nothing. The master server list is dated now as well, so I don't think you'll even find a server. But it was the first Mac Quake 2 server browser! Woohoo! Looks like they've taken down pages that don't get many hits, so it's not all there. I'm surprised it's still there -- I should probably ask them to take it down again. posted by ruffin at 6/12/2002 09:32:00 AM |
|
Tuesday, June 11, 2002 | |
Been awfully busy at work this week ("big" workshop based on an app I've written most of late this week), but I did have some time to play around with REALbasic (the "Mac version of Visual Basic") yesterday on my iBook when work was done. Though I was a little put off initially with how much different REALbasic is from Visual Basic where it really didn't need to be, within an hour I was enamoured. I managed to proof-of-concept everything I'd need to make a Quake 1 server pinger (something missing in OS X land right now) in minutes, something that took me a several hours to do in Java a while back. What's more, the GUI was incredibly more responsive than anything I'd made for OS X with Java, Swing or AWT. The build for Mac OS 9 made a similarly good looking app without changing a line of code, and even the Windows version looked great (see a very non-impressive screengrab here). All the advantages of Visual Basic were right there... on my iBook!! There was a quick IDE (move over, Netbeans) with something like "Intellisense", a GUI RAD (on the Mac!) like you wouldn't believe, and, after getting used to the new object model, a very Visual Basic-like experience that makes creating (if not coding) utilities with a GUI for Mac every bit as easy as VB utils for WinPC. Disadvantages include a nearly 800 Kbyte app on Windows (VB equivalent was 20kb, but that's not counting the vb virtual machine dll) which grew to 1.7 megs in OS X. It's also awfully expensive to make Win softare -- $100 for Mac-only builds and $300 for Mac/Win dual build. Sheesh! But I have to face facts -- if you want to target the Mac, REALbasic blows the doors off of Java, at least for simple apps. If you want to target a specific platform, which I do with many of my ideas for utilities, you should use platform specfic tools, I'm afraid. If you don't have a reason to use the Java platform any stronger than, "I'd like to hit a niche platform Java provides me access to", you're better off picking another, more specialized tool. Next is to figure out how to use REALbasic's "interactive shell" to open pipes to Java (and other) code. Just wrapping a REALbasic GUI over xplat code would do wonders for perceived performance. In other news, I found out that "Alt-Print Screen" take a picture of the active window in Windows so I can finally stop grabbing the whole screen and cropping that pic in IrfanView. Idiot! :^) posted by ruffin at 6/11/2002 03:58:00 PM |
|
Friday, June 07, 2002 | |
Macromedia releases software upgrades Dreamweaver MX sells for $399, or $199 for those upgrading from previous versions of Dreamweaver or ColdFusion Studio. ColdFusion MX Server Professional Edition costs $799 per server or $549 for the upgrade version. Fireworks MX sells for $299, or $149 for the upgrade. Studio MX is $799 for the full version, $599 for those upgrading from a single Macromedia product or $399 for those upgrading from two products. And as always folks, VIm is free. posted by ruffin at 6/07/2002 11:14:00 AM |
|
Woohoo! ASP.NET ROCKS!!! Can you say "Unchecked Buffer in ASP.NET Worker Process (Q322289)"? Microsoft must have put quite a bit of dough into buffer overflow exploit R&D recently... posted by ruffin at 6/07/2002 09:02:00 AM |
|
Thursday, June 06, 2002 | |
Been a little too busy to blog well, but I did get a kick outta this quote off of the Apple Java Dev listserv today: This performance problem has come out several times now and every times I observed the same behaviour: - Greg trying to justify this slow feature (Did you receive at least a new G4 from Apple Greg? ;-)) ) and suggesting ways to improve the computation time (but let's say the computation time will improve also on a PC, so the gap remain.....) - Apple employers don't saying nothing - new members complaining... - old members ignoring, tired of the discussion (except Greg :-o ) posted by ruffin at 6/06/2002 04:23:00 PM |
|
Tuesday, June 04, 2002 | |
Though I haven't spent more than a few minutes looking around, this Fusebox Web Application Standard seems to be a relatively interesting idea. Not too many people using it, it'd seem, and their specs are for ColdFusion and php (not exactly the mainstays of business logic -- I'd nominate asp/asp.net and jsp for that award), but the logic seems good. They seem to be saying, "Fuseboxes are a good metaphor for web app programming. Every room and/or utility in a house is hooked up to one fuse, and when that fuse goes out the rest of the house still has power." It's good for programmers to plan modular code. If nothing works when one piece of code is moved or blows up, you're often in trouble -- and you've got a bad app. At the same time, repeated code is pretty silly, which is one of the reasons I like asp.net [which makes it painfully easy to share code]. I'll have to see if these fusebox folk have the "right" middle road. Anyhow, somewhat interesting. posted by ruffin at 6/04/2002 12:09:00 PM |
|
| |
All posts can be accessed here: Just the last year o' posts: |
||||||||||||||||||||||
|