MacBook, defective by design banner

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 30, 2015

Well, all I needed to get *up and running* on JSP and Servlets (current project might be switching stacks) is here. Very good video package so far. Very basic, but thorough, which makes remembering all this stuff that I haven't used in probably 10-11 years pretty simple.

It's all different dialects of the same language, but it's useful to have a primer before changing regions.

I just heard someone on a Mac podcast complain about an irrational hate of Java. I don't get it. Java is a good language, other than the ivory tower syndrome that infests many of its stock objects. There's a reason Microsoft stole a lot from Java when they put together C#, to the point that I'm happy working in either for faceless code. Maybe Objective-C users are prone to another syndrome, Stockholm.

Labels: ,


posted by ruffin at 6/30/2015 11:39:00 AM
Thursday, May 07, 2015

So I'm unhappily debugging some inherited Python code, a language I've never used before, that's causing trouble (it's comparing .csvs, and was using giant dictionaries to keep all the rows from the first in memory, removing keys when a matching "id" column was found in the other file. But did it anticipate repeated keys in multiple csv rows? No. No, it apparently didn't), and got the attached "results" from googling for "python try catch". Hello, surreal...

And, as you can tell from the second picture, if you choose to play, after the search results are replaced by a command-line environment, things get a little Hideo Kojima-y. I remember once playing the original Metal Gear Solid with a buddy and running into Revolver Ocelot (?) in a boss battle, and he said something about how long it'd been since we'd saved, and that we weren't allowed to save now. I'm not even sure he was telling the truth, but we didn't try to save, and the battle was that much more exciting because of it.

So "This invitation will expire if you close this page," certainly convinced me into going down the rabbit hole. I mean, even if this is some sort of strange, elaborate hack, who wouldn't? I'm your huckleberry.

Turns out there's a file in my "home" directory called start_here.txt, and I'm given a programming challenge. Not too difficult, but a challenge, and a timer, and a time limit of 48 hours (I guess that was my first hint I should've waited until I was home). I don't know Python, but Java is allowed as well. Haven't really used Java seriously in a while, but I happen to have javac on the workstation (though no Eclipse or Netbeans), left over from when I decompiled an app we were using from [a vendor] to fix a bug of theirs (a casting error; they were pushing essentially a double into a single), so let's try this. A quick click on Sublime Text, a quickly hacked bat file to compile and run my class, a cmd window, and we're off.

The worst thing? I completely foobared the Google/foobar. What a freakin' idiot. I did sort of figure it was an application for employment, and I couldn't've done worse. The first problem wasn't tough, but I did my usual "race through and figure out errors later" and obo'd all over the place, which was obviously the point of the problem. I got it, but it took about 17 minutes of setup and fixing dumb errors. Idiot. I'm sure they see every failed verify call. Idiot.

Oh well. I logged in to save and guess I'll try the remaining tasks later. Not that I'm even looking for a job. Not that it's particularly ethical to interview me for a job while I'm working in my current position without telling me that's what we're doing. But that was fun, in a way.

This is what I get for searching to fix a Python issue! Programming languages are all "different dialects of the same language", a prof once told me. He was right, but it's strange what googling those dialects can do to you.

Anyhow, more about what's going on with Google/foobar here. And yes, it turns out it was an interview. Dang it. Still, from debugging Python in VIm via ssh to javac-ing an answer in 17 minutes isn't horrible, I guess. ;^)

Labels: , , , , ,


posted by ruffin at 5/07/2015 09:59:00 AM
Monday, January 14, 2013

jslint4java - A Java wrapper around Douglas Crockford's jslint tool. - Google Project Hosting:

This is a java wrapper around the fabulous tool by Douglas Crockford, jslint. It provides a simple interface for detecting potential problems in JavaScript code.

Labels: , ,


posted by ruffin at 1/14/2013 10:02:00 AM
Wednesday, October 10, 2012

Slightly slow, but ultimately pretty useful, videos on Spring (Java) and Hibernate.

Okay, I've only watch the first 7 or 8 Spring videos so far, and all on 1.5x or higher speed, but they are, if anything, overly accessible.

Labels:


posted by ruffin at 10/10/2012 09:04:00 AM
Wednesday, June 22, 2011

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: , , , ,


posted by ruffin at 6/22/2011 04:29:00 PM
Tuesday, October 26, 2010

Re: Are Java and Flash doomed on the Mac? โ€” RoughlyDrafted Magazine

Ah Dilger, the Jim Rome of Apple journaltisement.

The only problem is that developers use Java, not just to develop, but also for using xplat coding apps -- like Eclipse or phpStorm. Or SQuirreL-SQL. Java's a place that xplat partnerships can happen, even if the end result is a tool for coding [non-Java] rather than an end-user, client-facing app. That's exactly how Apple used Java in Mac OS X Server. There's a reason so many server admin tools started out with a Java GUI, and a reason WebObjects was Java.

And the more Java developers you have on OS X, the more developers you'll have considering and learning Objective-C.

So either Apple already knows Oracle's going to support Mac Java (which is a perfect world) or they're potentially misstepping, taking one too many lessons from the iPad back to the Mac.

Labels: ,


posted by ruffin at 10/26/2010 02:43:00 PM
Monday, May 25, 2009

From the Apple Quicktime for Java list in June last year, titled Re: QTJava will be depreciated next year:

I don't think Apple is really worried about losing mindshare in the Java video playback front. Java 7 has already promised on2 video codec support so playback in Java is a non-issue. ffmpeg, FOBS, FMJ, etc... are useless when it comes to meaningful editing so the question of editing support is the only meaningful one worth asking.
...
At this point, certainly, relying on Apple for Quicktime Java support would not be wise.


What's this on2 video codec we're talking about? I've been out of the hands-on loop long enough not to know about JavaFX. I can't say I completely understand what it's supposed to do (though JWebKit was supposed to follow it, and hasn't), but it appears to be QT4J's functional successor.

Downloading the JavaFX SDK Installer

Problem is, this would be a real bear to distribute, and the Mac sys reqs ain't exactly middlin'. Both make it less attractive than a well-supported QT4J (which we all know doesn't now exist, if it ever did).

Microsoft Windows:

* Processors: Intel Pentium 4, Intel Centrino, Intel Xeon, or Intel Core Duo (or compatible) 1.8 GHz minimum
* Operating systems: Microsoft Windows XP with Service Pack 2 or Windows Vista Home Premium, Business, Ultimate, or Enterprise (certified for 32-bit editions)
* Memory: 512 MB of RAM (1 GB recommended)
* Disk space: 256 MB free disk space
* Web Browsers: Internet Explorer 6 minimum, FireFox 2.0 minimum
* Java SE Development Kit (JDK): JDK 6 Update 7 minimum (JDK 6 Update 13 recommended)
The JDK installation includes the Java Runtime Environment (JRE).
* Apple QuickTime Player: 7.5.5 minimum is required to run the JavaFX Mobile Emulator, which is currently available only on the Microsoft Windows platform. System restart is required after QuickTime installation.

Apple Macintosh:

* Processor: Dual-Core Intel, PowerPC G5
* Operating system: Macintosh OS X 10.4.10 minimum
* Memory: 512 MB of RAM (1 GB recommended)
* Disk space: 256 MB of free disk space
* Web Browsers: Firefox 3.0 minimum, Safari 3 minimum
* Java SE Development Kit (JDK): JDK 5 Update 13 (version 1.5.0_13) minimum (Java for Mac OS X 10.4, Release 7 or Java for Mac OS X 10.5 Update 2 or later)
The JDK installation includes the Java Runtime Environment (JRE).


There's also some talk about how JavaFX is being pimped hand-in-hand with Netbeans, kinda like the essentially Netbeans-only VB-like GUI RAD I blogged about a long time ago and whose name I forget. I'm not quite sure I get the Netbeans infatuation. It's a nice dev environ, but I like Eclipse more. I'm still programming in Java, right?

So I'm not sure how much JavaFX is tied to Netbeans, as some conspiracy theorists trumpet, but I'm not completely sold that there's no proverbial synergy driving them either. I hate it when companies try to sell dancing moons and call them shovels (the tool du jour).

Labels: ,


posted by ruffin at 5/25/2009 07:45:00 PM
Sunday, September 07, 2008

Mr. Beal's cleverly named businessweek.com piece, Why Chrome Won't Crash Windows, misses a key point in understanding Chrome's importance. First, a quote:

It's our infatuation with the Google brand, more than the technology inside, that will boost Chrome's market share and further extend Google in our daily Web activities. As for being a Windows or Internet Explorer killer, don't count on it.


Did Gmail kill Hotmail? Will Google Docs kill Office? Did Google kill Yahoo? How about Google Reader -- it's killed nearly every stand-alone RSS reader I've tried.

Now each of these use the browser as their host platform. I've already shown Chrome's ability to take Google Reader offline. Does Firefox do this? Not yet...

If Chrome can extend Gmail, Reader, Docs, Maps, search, Scholar, Books, etc etc etc onto your desktop, the OS will finally become a commoditized complement. This kills Windows. Rather, it negates the advantage one OS has over another, in large and almost exclusive part.

Again, Google is with chrome making Java's play, and they are, to date, doing it successfully. There's more than just a cute icon to be gleaned from Google's portrait of Java applets as a bunch of dancing moons. What Google is saying is that where Sun failed so miserably and laughably in Web 1.0, Google's winning in version two.

Google is killing the OS in ways Sun wanted to with Java and couldn't. It'll be interesting to see if Google can succeed.

Labels: , , , , , , , , ,


posted by ruffin at 9/07/2008 08:31:00 PM
Sunday, June 22, 2008

I've been looking at using JSmooth, an open source package that wraps Java apps into Windows exe. Apparently Azureus used to use it, at least before it became Vuze. JSmooth hasn't been updated in quite a while, but I'll give it a run this week on 1.6 and see what happens.

Windows: First Steps in Wintegrating Java Apps:

There are mutliple steps to properly providing integration on Windows, and I briefly mentioned them above, installers and executables. These items together are actually a rather large subject, so I plan to split them up. Today I'm going to talk about producing portable executables for Java applications through a program called JSmooth.

Labels: , ,


posted by ruffin at 6/22/2008 01:30:00 PM
Monday, June 16, 2008

Artem Ananiev's Blog: Introducing JWebPane component:

For many years, Java lacked a worthy component to render HTML content. HTML support in Swing was limited to the 3.2 version. Although the SwingLabs JDIC library provides a browsing component, it is hard to integrate into Swing applications because of its heavyweight implementation. The new component - JWebPane is not intended to substitute all known alternatives, however, it brings HTML support and easiness of use up to the high-level standard.


The state of displaying html with Java stand-alone applications has been pitiful for years, even while other desktop app solutions include native, robust solutions. The new JWebPane is really a pretty neat idea if they're doing it as Mr. Ananiev describes. Effectively, they'll building everything needed to host the xplat components of WebKit in Java.

JWebPane is based on the widely recognized open sourced engine - WebKit. It is not a secret any more. :) The WebKit architecture consists of two considerable parts. The first one is cross-platform, it is responsible for parsing documents, generating DOM, supporting JavaScript. Another part, platform-dependent, so called "port", is intended for communicating with network, rendering graphic content on the screen and other devices, event handling, and other features. JWebPane is a Java port, in which all cross-platform calls are implemented in Java.


But now, back to reality. I'm a little surprised to see Ananiev say that it's "not intended to substitute all known alternatives" when the known alternatives are all so horrendously flawed. Add to that some quotes fromThe Java Tutorials' Weblog.

The following new features are scheduled to be implemented by August'08:

Viewing the History, including Back and Forward functions.
Notifications of external resources loading
Progress status
Viewing page source


August, eh? It's also described as only "70% complete" yet they show demos of how to embed this 70% upside-down and crooked in your frame. Useful.

I did like this quote from the JavaOne Presentation that introduced this component explaining one of its uses.

Web Content to Enrich Applications
Why embed a โ€œstreetโ€ HTML viewer in you application?
โ€ข Show web advertisements (and make some money!)...

Labels: , ,


posted by ruffin at 6/16/2008 05:43:00 PM
Thursday, June 12, 2008


Okay, this policy of Gmail stinks, especially when you're a programmer trying to distribute applications you've built:

Some file types are blocked
As a security measure to prevent potential viruses, Gmail doesn't allow you to send or receive executable files (such as files ending in .exe) that could contain damaging executable code.

Gmail won't accept these types of files even if they are sent in a zipped (.zip, .tar, .tgz, .taz, .z, .gz) format. If this type of message is sent to your Gmail address, it is bounced back to the sender automatically.


This fails the "do no evil" test. Why would Gmail shut down sending applications? Viruses, sure, but is there another reason a company who"outlines Web development investments in three areas", one of which is "2. Keeping Connectivity Pervasive" might want to discourage the distribution of applications on the desktop?

Look, the browser is the platform for Google. They want to replace exe with http. This is exactly what scared Microsoft when Java hit the scene -- that Microsoft's hold over the desktop would become meaningless as applications moved to the web.

Java failed in its attempt to take over the desktop, but it weakened Microsoft enough that Google's been able to do it (look, I realize that's a stretch, and I've left out about three hundred and two points between Java and Google, but hey, this is a blog post. For now, I'm going to have to ask that you trust me.). AJAX is the new Java. The web is winning.

That Google would stop you from sending exe's via their new https should come as a surprise to no one. I'm not saying they instituted the policy to stop one from sending competitors to their platform, but it's sure as heck one reason if the decision isn't at least partially reversed in the future.

Labels: , , , , ,


posted by ruffin at 6/12/2008 05:06:00 PM
Tuesday, May 27, 2008

From Chapter 5. of Processing XML with Java, "Reading XML":

The main point is this: most programs you write are going to read documents written in a specific XML vocabulary. They are not going to be designed to handle absolutely any well-formed document that comes down the pipe. Your programs will make assumptions about the content and structure of those documents, just as they now make assumptions about the content and structure of external objects.


That's really an intelligent way of coming at reading XML, and it's the way I argue is the way it should, in about 75% of real world cases where XML is used, be done. That Harold does it, even tongue in cheek, is far more important than my recommendation, of course. His books on Java are top rate stuff, imo. The bottom line here is that you know darn well what the XML file you want to read is going to look like. Why put in any libraries for parsing it all out that you don't absolutely need? KISS.

Here's some of the code where he's reading out the XML from his specific example.

private static BigInteger readFibonacciXMLRPCResponse(
InputStream in) throws IOException, NumberFormatException,
StringIndexOutOfBoundsException {

StringBuffer sb = new StringBuffer();
Reader reader = new InputStreamReader(in, "UTF-8");
int c;
while ((c = in.read()) != -1) sb.append((char) c);

String document = sb.toString();
String startTag = "";
String endTag = "
";
int start = document.indexOf(startTag) + startTag.length();
int end = document.indexOf(endTag);
String result = document.substring(start, end);
return new BigInteger(result);

}


I think you can see what's going on. Honestly, that's the right way to do it in what is a much more common, real-world situation than one might suspect. Now granted, Harold adds...

Straight text parsing is not the appropriate tool with which to navigate an XML document. The structure and semantics of an XML document is encoded in the documentโ€™s markup, its tags and its attributes; and you need a tool that is designed to recognize and understand this structure as well as reporting any possible errors in this structure. This tool is called an XML parser.


But think of how many times you've seen XML used -- essentially as a text file. There's absolutely no reason to learn all the new APIs necessary to parse XML in these cases. You could just as easily have created your own file format, but then I understand why one might use XML instead. There is structure that would take weeks for a typical programming team to put together in conference. Why not lean on an over-engineered structured for your flat files? If you do step past known, easy to consume formats, then you don't have to re-engineer to use XML APIs.

XML's strength is to compose very large batches of structured data for anonymous consumption, but that doesn't mean that's the way it's most commonly used, nor the only way that XML's structure can be used. Let your approach, both for the file and the parsing, match your needs.

Labels: ,


posted by ruffin at 5/27/2008 12:33:00 AM
Monday, May 26, 2008

UPDATE: Okay, marginally I understand what I was doing in the post, below, but I have no idea what problem it fixed. The description is awful. I mean, it must have done something for me, but I now have no idea what. Way to go, self.


So spaces come before letters, either case in our good friend, the American Standard Code for Information Interchange. This is a pain, because it means Java's Collections' binarySearch is going to tell us an entry for "special sauce" should come before "special", which probably isn't what we wanted. So we've got to write our own Comparator to make things pop out the right way.

Here's what I've got so far. Enjoy. Well named, I might add.
(c) 2008 Bailey
package com.rufwork.run;

import java.util.Comparator;

public class JoeComparator implements Comparator {

public int compare(Object arg0, Object arg1) {
int intReturn = 0;
String strFirst = arg0.toString();
String strSecond = arg1.toString();

int intShorter = 0;

if (strFirst.length() < strSecond.length()) {
intShorter = strFirst.length();
} else {
intShorter = strSecond.length();
}

int i = 0;

while (0 == intReturn && i<intShorter) {
int intCharForFirst = strFirst.charAt(i);
int intCharForSecond = strSecond.charAt(i);

// we want "space" to come *after* all chars
// otherwise "special sauce" comes *before*
// "special"
if (32 == intCharForFirst) {
intCharForFirst = 257;
}
if (32 == intCharForSecond) {
intCharForSecond = 257;
}

if (intCharForFirst < intCharForSecond) {
intReturn = -1;
} else if (intCharForFirst > intCharForSecond) {
intReturn = 1;
}

i++;
}

// we only know right now that the strings are the same
// to the length of the shorter string.
if (0 == intReturn) {
if (strFirst.length() < strSecond.length()) {
intReturn = -1; // strFirst comes first
} else if (strFirst.length() > strSecond.length()) {
intReturn = 1;
} // if they are the same length, stay at 0
}


if (false) { // some debugging jive
if (1==intReturn) {
System.out.println(strFirst
+ " is larger than " + strSecond);
} else if (-1==intReturn) {
System.out.println(strSecond
+ " is larger than " + strFirst);
} else if (0 ==intReturn) {
System.out.println("Same strings: "
+ strFirst + " :: " + strSecond);
} else {
System.out.println("Something wack happend: "
+ strFirst + " :: " + strSecond);
}
}

return intReturn;
}

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub

}

}

Labels: , ,


posted by ruffin at 5/26/2008 11:38:00 PM
Saturday, May 24, 2008

I've been a little neglectful keeping on top of Java 6, but my recent trip to the Java Tutorial, which has in my experience been one of the best "how to" programming sites on the net, shows me that the marketing guys have infiltrated this once idealistically perfect site.

Here's what I saw.

How to Use Text Areas (The Javaโ„ข Tutorials > Creating a GUI with JFC/Swing > Using Swing Components):

The TextAreaDemo example introduces an editable text area with a special feature โ€” a word completion function. As the user types in words, the program suggests hints to complete the word whenever the program's vocabulary contains a word that starts with what has been typed.


That's exactly what I needed. I'd been looking at some solutions with more functionality, where you start typing a word and a number of possibilities appears in some sort of select-list below, including the Netbeans editor and a few examples from weblogs. Each was more overhead than I wanted, and just short of writing some simplistic autocomplete code, I stumbled over this.

So where's the marketing? How about the stuff that's Java 6 only, like the incredible overkill of the Java 6 only GroupLayout? Sure, you can add GroupLayout to your 1.5 and possibly 1.4 application, but why do I need this for a form with a single label and single text area?

Let's look at the code. Here's the layout jive necessary with GroupLayout.

GroupLayout layout = new GroupLayout(getContentPane());
getContentPane().setLayout(layout);

//Create a parallel group for the horizontal axis
ParallelGroup hGroup =
layout.createParallelGroup(GroupLayout.Alignment.LEADING);
//Create a sequential and a parallel groups
SequentialGroup h1 = layout.createSequentialGroup();
ParallelGroup h2 =
layout.createParallelGroup(GroupLayout.Alignment.TRAILING);
//Add a scroll panel and a label to the parallel group h2
h2.addComponent(jScrollPane1,
GroupLayout.Alignment.LEADING,
GroupLayout.DEFAULT_SIZE, 212,
Short.MAX_VALUE);
h2.addComponent(jLabel1,
GroupLayout.Alignment.LEADING,
GroupLayout.DEFAULT_SIZE, 212,
Short.MAX_VALUE);

//Add a container gap to the sequential group h1
h1.addContainerGap();
// Add the group h2 to the group h1
h1.addGroup(h2);
h1.addContainerGap();
//Add the group h1 to hGroup
hGroup.addGroup(Alignment.TRAILING,h1);
//Create the horizontal group
layout.setHorizontalGroup(hGroup);

//Create a parallel group for the vertical axis
ParallelGroup vGroup =
layout.createParallelGroup(GroupLayout.Alignment.LEADING);
//Create a sequential group
SequentialGroup v1 = layout.createSequentialGroup();
//Add a container gap to the sequential group v1
v1.addContainerGap();
//Add a label to the sequential group v1
v1.addComponent(jLabel1);
v1.addPreferredGap(LayoutStyle.ComponentPlacement.RELATED);
//Add scroll panel to the sequential group v1
v1.addComponent(jScrollPane1,
GroupLayout.DEFAULT_SIZE, 100,
Short.MAX_VALUE);
v1.addContainerGap();
//Add the group v1 to vGroup
vGroup.addGroup(v1);
//Create the vertical group
layout.setVerticalGroup(vGroup);
pack();


Now here's what I need to get the same form, give or take, with layout code that'll work with every version of Java since Swing was released as an add-on jar. (Why bother? Mac OS X 10.4 has Java 1.5, not 6, and no GroupLayout by default. Sounds like a decent reason to me.)

BorderLayout layout = new BorderLayout();
getContentPane().setLayout(layout);

this.getContentPane().add(jScrollPane1, BorderLayout.CENTER);
this.getContentPane().add(jLabel1, BorderLayout.NORTH);
this.pack();


That's right, the code becomes more readable and compatible. Mr Pibb + Red Vines = Crazy Delicious!

Maybe I'm an old-school idealist, but I don't believe in including a single extra line of code, much less a major code concept, in a tutorial than is absolutely necessary. Tutorial code should be designed to be written by hand, and should encourage its users to make small changes to see how those changes influence what happens. With GroupLayout, it's very difficult to add another few GUI widgets, difficult enough that the Tutorial itself tells us so on its page regarding how to use GroupLayout. Don't miss the Netbeans pimp in the following quote.

Note: This lesson covers writing layout code by hand, which can be challenging. If you are not interested in learning all the details of layout management, you might prefer to use the GroupLayout layout manager combined with a builder tool to lay out your GUI. One such builder tool is the NetBeans IDE. Otherwise, if you want to code by hand and do not want to use GroupLayout, then GridBagLayout is recommended as the next most flexible and powerful layout manager.


That last sentence is particularly bad marketing speak. See how they ignore the fact that saying "if you want to code by hand" is a superset of "do not want to use GroupLayout," the latter left in solely to deaden the [admittedly small] shock of what they just told you -- GroupLayout is for IDEs, not text editors. And the pseudo-objective tone of "One such builder tool is the NetBeans IDE," is borderline obnoxious.

For older school programmers, that paragraph would read, "GroupLayout was created to help support GUI RAD in Netbeans, and works best in concert with that IDE. GridBagLayout is the most flexible and powerful layout manager created with hand-coding GUIs in mind." Alternately, for even older school folk, the text would be, "GroupLayout is not for hand-coded GUIs. Use GridBagLayout or BorderLayout instead." And a comment in the TextAreaDemo example saying, "This code intended for use in Netbeans," or something similar explaining why the horribly unwieldy layout manager was used, if it has to be there, would have been nice.

Tutorials should present simplest case information that allow an informed programmer to learn a new trick in a simplest case, clean room environment, and then have the tools to figure out how to best integrate that into his or her work flow and environment. Pimping a specific Java IDE has absolutely nothing -- no, I hear your argument, and trust me. They have nothing to do with one another -- to do with learning to use JTextArea. Learning how to introduce JTextAreas using Netbeans is Netbeans' business. Doing it in Eclipse is Eclipse's business, etc.

I don't care to see the IDE wars inserted into my tutorials. It's painful to see that Sun now prefers the opposite.

Labels: , ,


posted by ruffin at 5/24/2008 10:47:00 PM
Monday, August 27, 2007

I'm not sure why Sun's Java coders don't support a sort of minimalist mindset as part of their Ivory Tower Syndrone, but they don't. This is not news, and I believe I complained about this the last time I acquired a Windows laptop and was trying to find a decent RSS aggregator. Regardless, it hurts to see the pain again.

JNN is a decent RSS aggregator, notoriously referred to as James Gosling's "weekend hack." It did all your RSS reader needed to do. Unfortunately it's since had one heck of a lot of dependencies added to it, which I'll paste here for those not lucky enough to be registered java.net members.

File  Rev.  Age  Author  Last log entry
bloged.jar
cmu_us_kal.jar
cmulex.jar
cmutimelex.jar
en_us.jar
freetts.jar
jaxen-core.jar
jaxen-jdom.jar
jdom.jar
jsapi.exe (??)
jsapi.sh (??)
rome-0.8-HEAD.jar
saxpath.jar


It's annoying when people make code this incestuous. I'm not going on a limb when I say the full power of each of these libs is not necessary for the application to work, but occasionally JNN utilizes only a few functions from a library because whatever developer (here's one possible culprit of many) was familiar with that other project.

I hate dependencies. If you're going to add them, make the application degrade gracefully if they aren't found. Right now, JNN just stops at its splash screen without so much as a dialog box. Slick. And for heaven's sake, include the danged libraries in the download to your app from the app's home page. Can this really be the home of the sorry as crap DefaultModels for their GUI renderers? (That is, when developing with Java, the kitchen, at least with respect to GUIs, is so bare/minimalist that it's nearly unusable, forcing you to roll your own objects rather than leaning heavily on the libraries.)

Skillz-a-plenty. Hopefully I'll finally bother to CVS the initial version and fork this one into something usable from a hacker's point of view.

Labels:


posted by ruffin at 8/27/2007 10:09:00 PM
Sunday, July 10, 2005

The LGPL and Java:

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work.

That's why the LGPL is no good; this is an exploitable hole to allow people to modify a library and start reverse engineering your code, it would seem. I'm not real sure why that's bad, but I do know it's not something I'd particularly want butting up next to my proprietary code.

Perhaps this is why a number of pay-to-play companies run a secondary, "Free as in Mozilla Public License" codebase. Having grown out of the need to recreate Netscape, not to become part of an idealistic Hurd, the MPL watches companies' backs well. Too well.

Here's the metaphor I heard that got me interested in the LGPL (IANAL):

You're making a calculator. You've got every button down except the square root button. You decide to look at external libraries to save time.

GPL Square Root -- You can embed the function and sell your software, but now every bit of your calculator, plus, minus, 1s, 5s, the whole thing, must be released with full source code. Now anyone can take your code and sell your application. Anyone. Not necessarily a bad thing, unless you like to make money. Everyone can use your first-rate natural log function, but do remember that they, too, can't sell this [legally] without showing the code to anything they've added. Great for promoting passive collaboration.

LGPL Square Root -- Originally, before the Java issue, I thought the LGPL went like this: You can add this square root function, release and sell your app. You only have to include source to the square root function; everything else can stay proprietary. Let's say, however, that you find a bug in the square root function, say it thinks the square root of 49 is 8, but gets everything else right -- or that it only goes to 5 decimal places. If you fix the bug or extend its accuracy to 10 decimal places, you have to release the source to those improvements with your app. Personally, that's great so far. I like it. If you only have the function b/c of someone else's contribution, you owe it to him/her/them to release your improvements for all to use. It enables passive collaboration, but still allows you to protect your investment. Nobody "deserves" your fancy natural log function if you don't want to give it to them. It was entirely your work. Keep it. The "rights" to the code are protected from both sides, and fairly. You'd also owe the 'LGPL' a big thank you, of course, but you get the point.

BSD Square Root -- Take it. Sell your app. You might have to acknowledge the project whose work you took, but that's it. It's yours. Take it from 5 to 10 decimal places of accuracy, heck, take it to 2000, and you don't have to share a keystroke. Great for greedy people who don't want to be bothered, but I'd hope they'd feel a little bad about taking work to which they didn't -- nor will -- contribute.

MPL Square Root -- You can take this square root function, release, and sell your app.  In fact, you could (afaict) take your own square root implementation, take a few files from the MPL version, and put those together to be released.  Your own, wholly original code could stay closed, and only changes you made to MPL files would need to be released.  Initially, I thought the MPL was like BSD.  As is obvious here, it's not.  It's sort of like the LGPL in that your code can be released in support of and as part of a closed source product, but it's "file-level" in that any file of your library could potentially be taken and used in a new context.  But it's as close to the LGPL as you can get if you want to allow someone to compile your code alongside proprietary code, and it doesn't seem exceptionally evil.  It's a good deal less protective than the LGPL, but just good enough that I still like it.  (MPL section added 20131011.)

Okay, comparison over. But now, following the relatively dated quote about Java issues, above, (iff the Java issue is legit) the LGPL forces anyone using the square root function to allow anyone to decompile their entire app that uses the square root function to "bug check" against their code.

That's simply not a place I want people going. Short of the square root function, it's my code. Stay out. If you want my code to work, use the old library that thinks 49's square root is 8. If you can upgrade the lib to work with 49, great, but why should I have to give you any rights to my code downstream of the square root function to make that happen? You didn't make the investment in app, and I want to protect it. That should be my right. You shouldn't get to peek at my natural log function if I've used LGPL code elsewhere. If your change to the square root -- and who knows how inane that change might be; perhaps it also now doesn't do 36 correctly -- breaks compatibility with my app, that's my problem. I'll fork the square root lib if I have to.

Oh well, guess I'll eventually have to start my GNG (GNG's Not GNU) movement with an LGPL done, if not right, then fair. Might be as easy as slashing Section 6 in the LGPL; I'll have to check sometime. Now, on to UO (I'm on sabbatical from WoW)!

Labels: , ,


posted by ruffin at 7/10/2005 02:27:00 PM

<< Older | Newer >>


Support freedom
All posts can be accessed here:


Just the last year o' posts:

URLs I want to remember:
* Atari 2600 programming on your Mac
* joel on software (tip pt)
* Professional links: resume, github, paltry StackOverflow * Regular Expression Introduction (copy)
* The hex editor whose name I forget
* JSONLint to pretty-ify JSON
* Using CommonDialog in VB 6 * Free zip utils
* git repo mapped drive setup * Regex Tester
* Read the bits about the zone * Find column in sql server db by name
* Giant ASCII Textifier in Stick Figures (in Ivrit) * Quick intro to Javascript
* Don't [over-]sweat "micro-optimization" * Parsing str's in VB6
* .ToString("yyyy-MM-dd HH:mm:ss.fff", CultureInfo.InvariantCulture); (src) * Break on a Lenovo T430: Fn+Alt+B
email if ya gotta, RSS if ya wanna RSS, (?_?), ยข, & ? if you're keypadless


Powered by Blogger etree.org Curmudgeon Gamer badge
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity.