No Open Blockers

RHQ… now with 100% more awesome.

The release can be downloaded and full release notes found at the RHQ wiki.

Changes in this release include:

• Repo Synchronization – The ability to schedule package synchronization for specific repos as well as cancel a running sync.
• HTTP Content Access – The ability to browse content repositories and retrieve packages via HTTP.
• Server-Side Plugin Dynamic Configuration Values – Added the ability to indicate the enumerated values for a configuration property of a server-side plugin be pulled from the database. For more information see Server Plugin Descriptor Configuration.
• Raw Configuration Support – Significant enhancements made to raw configuration support.
• Notification Templates – It is now possible to create bundles of pre-configured alert senders that can be applied to individual alert definitions.
• Alert UI Revamp
• Server Side Plugins Operations – Server-side plugins now support operations.

I’m not completely sure why, but I’m a bit embarrassed to admit to Planet Fedora how little my Python experience is; the majority of my experience is in Java. I was able to read and bug fix the Python code in Spacewalk, but I hadn’t really dug deep into my own project. Now that I’m not teaching any longer and have some free time (one of my main reasons for quitting), I can finally sit down and dork around with the language. After spending some time working on some basic games and a simple IRC bot, I figured I’d step back and think about what the transition from Java to Python has felt like.

Don’t Fear The Whitespace

I constantly hear people mention the indentation in Python as the first thing when talking about moving to the language. Not only is it not as jarring of an experience as people make it out to be, it’s downright awesome. I’ve always been compulsive about my code format anyway, so the biggest difference is the lack of curly braces.

Collections Are Awesome

It’s much lighter-weight to throw things into a list or map (dictionary in Python) than it is in Java. Get out of the mentality that you have to jump through import hoops and rigid notation to create, access, or return collections. In Python, they even let you do cool things like assign multiple variables as a return from a call:

exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()

Looping Feels Weird At First

I got a little thrown off by this initially. Most loops read really well:

for square in openSquares:

However, when looping through a set of numbers, you need to use the range method:

for i in range(0, 10):

Looking at both of those examples brings me to my next point…

Don’t Forget The Colon

This keeps throwing me off, but after declaring a function*, loop, or if statement, don’t forget to end the line with a colon. I’m happy to be rid of curly braces, but I get over-ambitious and forget the colon too.

Don’t Over-engineer Configuration

Depending on what you’re doing, you can likely just stuff configuration values into a script and import it (not needing to compile really is liberating in this respect). That’ll also give you the use of lists and maps by default. If you’re not reading between the lines I’ll spell it out: no need for XML-based configuration, which is one of the more evil trends in Java.


There are definitely more things I could mention; don’t take this to be the only lessons I’ve learned (any other hints/tips are appreciated). But I do want to avoid a mammoth blog post that causes readers to go into a zombie-like trance, so I’ll stop it here for now. I do want to thank Devan (dgoodwin) and Jesus (zeus) for dealing with the Java-veteran-turned-Python-noob and not finding a way to crash my chat client to avoid more questions.

* I haven’t seen a solid explanation of “Call them ‘functions’ because you’ll sound like a Java guy calling them ‘methods’”, but this feels like something where using the wrong term will make me stand out as a Java developer in a Python world. So I’ve been advised to take a militant approach of “Yes, I’m a Java guy learning Python, deal with the occasional terminology missteps.”

So far we’ve created a NetBeans project and written and compiled our first class. What do we have to show for it? A few directories and a Java file.

Big deal.

Thankfully, that’s just the beginning. Now that we’re at a point where we can start to code, the fun stuff begins. Ultimately I want to cover writting/running test cases, using a debugger, refactoring, and building/running executable JARs. But first, let’s take a look at some of the perks the NetBeans editor gives us.

Autocomplete

Autocomplete is one of my most used features in an IDE. The idea is that since Java is strongly typed* you can have NetBeans tell you possible methods that can be executed on an object given its type. To trigger the autocomplete, type the period after the object reference and press ctrl+space. A drop-down will appear showing the possible methods that can be invoked on that object.

* If you don’t know what that means just yet, your professor had better cover it.

In the above example, the drop-down shows all methods that can be executed on the out object. Most students will be familiar with the println method, however the autocomplete shows there are a number of other methods exposed by the out object that can be called. Keep in mind that in this case I didn’t scroll down far enough to show the println(String s) method which most students have used in the past. It’s still there, it’s just not shown in the screenshot.

Below the drop-down is the javadoc for the currently selected method (println in this case). This displays whatever documentation the author felt was necessary to properly use the method, including a description of what is returned and explanations of any parameters the method takes.

Syntax Highlighting

Take another look at the above screenshot. Notice how the System.out snippet is underlined with a wavy red line (is there an actual name for that style of line?). Also notice the line number has been replaced with a warning indicator. Both warnings indicate that the line is invalid and won’t compile. In this case, what we’ve typed (System.out) isn’t a valid line of code. Once this is completed, for instance with a call to println and a semicolon, the warning indicators will go away.

This is a great teaching assistant for new programmers. Compiler errors can be… well, they aren’t always all that clear. Hovering over the code marked as invalid will display a tool tip describing the error. In this case, hovering over the snippet displays “not a statement”. This can be a tremendous help when still learning the syntax of the language. It’s not just for beginners either. Many veteran programmers appreciate the extra pair of virtual eyes that the IDE provides through this mechanism.

Code Templates

I referred to this in an earlier blog entry, mistakenly using the IntelliJ term “Live Templates”. The concept is the same in both IDEs. The user types a short abbreviation and uses the tab key to have the IDE automatically expand it into full code.

To see the templates provided by default in NetBeans, navigate to the Tools -> Options menu item, select Editor from the top set of icons, and Code Templates from the tabs below. There are a number of them defined, so rather than sit there attempting to memorize them all, here’s a quick list of ones I regularly use and the text they expand into:

• psvm – public static void main
• psfs – private static final String (useful for defining local constants)
• sout – System.out.println()

You’d be surprised how useful it becomes, especially if you’re a slow typer. Between these and the autocomplete, we’ve already addressed two powerful features to limit how much code you actually have to manually type. I’d guess I only ever fully type out about 10% of the code I write.

In addition to the default templates, users can create their own. This can come in especially handy when you’re working with a particularly verbose API. I won’t get into the full specifics on the syntax of defining a template now, but it’s worth taking a quick look at the “sop” template:

System.out.println("${cursor}");

Notice the odd ${cursor} piece in the middle. That’s an example of the variable capabilities in the template definition. The ${cursor} snippet will leave the cursor in that position after the text is expanded. That makes sense, since you’ll likely want to type something into the parameter (notice the quotation marks are included in the template definition).

There are more possibilities for these syntax variables. The help button on that screen provides a link with more description. I’m not necessarily suggesting that a new Java developer dive right into defining complex code templates, but at least knowing it is there for future reference is valuable.

Comment a Line of Code

Pressing ctrl+/ at any point in a line of code will comment out the entire line of code. Pressing it again will uncomment the line. It may sound dumb, but when you’re incrementally debugging a block of code, you may find yourself using this quite frequently.

I’ll stop there for now. Too much at once will just start to melt brains.

I don’t have a specific “Editing Part 2″ in mind just yet, but I’m sure there are editing features I cannot live without that I have yet to touch on. We’ll see where my blogging motivation takes me next in this series.

Once the NetBeans project is created (blog entry here if you missed it), we can get coding. Rather than abstractly going over the NetBeans UI, I’m just going to dive into getting the Hello World application running.

First off, go ahead and close the Start Page tab. It’s just in the way right now.

Creating a Class

You can ask NetBeans to create a class either through the File -> New File option or by right clicking on the Source Packages listing in the Projects tab to the left (it should be under a tree root called “HelloWorld”, which is the Project Name specified back at project creation time) and selecting “Java Class”. I prefer the latter option.

This brings up the new class creation screen which looks more daunting than it actually is. There are two important fields here. The Class Name field is exactly what it sounds like: the name of the class being created (don’t forget proper capitalization). The Package field indicates the package in which the class will be put, creating the package if it doesn’t exist (if you don’t know what a package is, leave this blank for now, soon enough this will be covered in class).

NetBeans will generate and display the exact path to the file being created. Notice that the file is put in the src directory (unless you accidentally right clicked on Test Packages initially). Also notice that if a package is specified, NetBeans will create the appropriate directory structure below the src directory.

Bitter Old Coder Comment: Just because NetBeans will put the class in the correct directory based on the package, don’t get lazy and fail to understand what that structure should look like. If the sheer knowledge isn’t motivation enough, realize it will be a question on one of my exams.

In the above screenshot, a new class named MyHelloWorldApp will be created in the default package. Once the Finish button is clicked, the new class will be opened in an editor tab. NetBeans will take care of some of the basic structure of the class, including class declaration and some basic javadoc comments.

Implementation

This section could be huge if I were to go into the various code writing assistance tools NetBeans offers. I’ll cover those more in future entries. For now, we’ll stick to the basics.

Navigate the left pane under Source Packages to find your class (trust me, this will look more interesting once packages are involved). If the class isn’t open, double-click the file to open it in an editor tab. I’ve provided a simple main method below:

public static void main(String[] args) {
    System.out.println("Hello World");
}

Compiling

There are a number of ways to compile depending on how much of the project you want to build. For now, I’ll stick with the left-pane-centric approach and suggest to right click the tree root (HelloWorld) and select Build.

So what just happened? Like last time, let’s look at a file browser to see what NetBeans actually did.

In addition to the three directories created when the project was first created, there are two more now.

• build – A build directory is used as a temporary directory into which project pieces are, well, built. Since we’re just dealing with a simple application here, the only task in building is to compile the classes, placing the resulting compiled classes in the classes directory. I say “temporary” in the sense that you should be able to delete it and recreate its contents by building the project.
• dist – The dist directory represents a fully built application ready to be distributed. For now, this will likely just be a JAR file containing all of the classes in the project (I won’t get into the details of what a JAR is yet). This is also where NetBeans will place the generated javadoc HTML files if they are created (the Run -> Generate Javadoc command if you’re curious).

One thing I really like about NetBeans is that the project structure is consistent with many Java projects. Once you get accustomed to the ideas of what belongs in a src or build directory, it becomes pretty simple to navigate virtually any other Java project (for instance, the many open source projects available).

Also notice the source file for the class, MyHelloWorldApp.java, has been created under the src directory. Again, if this class were in a package, the package directory structure would be present under the src directory.

Running

Since the MyHelloWorldApp class contains a main method, it can be run through the java command or, more to the point, through NetBeans. Again, there are a number of ways to do this and again, I’ll stick with the approach that focuses around the Projects tab in the left-hand navigation. Right clicking on any file that contains a main method will have an option in the menu for Run File. Selecting that option will run the main method of that class.

The section beneath the editor tabs contains any output from the execution. In this case, it’s simply the output of the main method’s println statement.

run:
Hello World
BUILD SUCCESSFUL (total time: 0 seconds)

For now, don’t worry about what the “BUILD SUCCESSFUL” message means. While this showcases one of what I believe to be cooler aspects of NetBeans, it’s too much to explain right now. Suffice it to say, the word “successful” is good while “failed” isn’t.

Happy Coding

At this point, we’ve covered the minimum necessary to start coding in NetBeans. There are still a ton of useful features that I’ll cover in future posts, but this should be enough to get to a point where you can start to experiment and play around.

At the end of last semester, I got together with a group of other CSC professors at Villanova to discuss the Algorithms & Data Structures I, II, and III curriculum. One of the topics of this meeting was how to introduce the students to using an IDE (wikipedia link). After a bit of research, the choice was made to go with the open source NetBeans IDE.

While I plan on covering aspects of NetBeans in class, I figured it’d be useful to have a written explanation for my students to refer back to. The NetBeans provided quick start guide is good, but it’s largely geared towards existing developers comfortable with a Java project structure. So over the course of a few blog entries, there are a few topics I want to highlight that are relevant to the projects in my class.

Installation

Installation, however, is not one of the topics I want to cover. To be blunt, I run Linux (regrettably most of my students don’t) and I don’t have a Windows box around to figure out the instructions for that platform. Instead, I’ll simply link to their download page and their install instructions. I suggest that my students download the “Java SE” download bundle from their download list (the “Java” bundle contains a number of extra features that are not used in class, so not including them will limit the amount of noise and distractions in the UI).

Creating a Project

NetBeans, or more generally most IDEs, aren’t used in the same way as a simple text editor. Instead of just opening one file to edit at a time, you first set up some sort of context around the source code. This is typically called a “project”, but don’t be surprised to see words like “module” or “workspace” used in a similar fashion.

Organizing code into projects has a number of benefits. A project keeps related classes linked. For instance, an online store would need classes such as a ShoppingCart, User, PurchaseItem, and so on. Keeping all of these classes in the same project will allow them to “see” each other and be used together for the application. If this seems confusing at first, don’t worry; many students are not introduced to multi-class programs until the basics have been covered. To my students specifically, I can vouch for the fact that this should be clear as our semester progresses.

Creating a new project in NetBeans starts at the File -> New Project menu. This kicks off the project creation wizard.

Step 1

The first step is to select a template for the type of project you’re creating. While there are a lot of options to choose from, many are just subtle variations on others. The default (Java -> Java Application) is a good starting point to get an empty project. Make sure this is selected and press Next.

Step 2

The next step is to specify where the project files should be created and stored. You’ll be asked for the following things:

• Project Name – This is usually just a user-friendly name you give to your project. NetBeans, however, also uses this as the name of the project directory (more on that later). For now I’ll just use the typical programming standby of “HelloWorld”.
• Project Location – This is a bit misleading. This is the root of where your specific project directory will go (again, more on this later). My suggestion for my students is to create a new directory (i.e. folder) to specify here that all class project will be stored in. For example, C:\Documents and Settings\jdobies\csc1052. Don’t be confused by my screenshot; Linux directories look a little different than on Windows.
• Project Folder – This is automatically determined by NetBeans (and annoyingly can’t be changed) by using the Project Name as the name of the directory inside of the Project Location. So given the above two examples, the project folder will be created as C:\Documents and Settings\jdobies\csc1052\HelloWorld.

A small clarification of my suggestion from above: Specify the same Project Location (i.e. the csc1052 directory) for all projects for the semester, using a different Project Name each time to reflect each project. This way, all project code will be located in the same place, organized in folders based on each individual project.

I also suggest unchecking the “Create Main Class” option. It’s simply a shortcut to making a class for you, but that’s easy enough to do later. Personally, I’d rather start with an empty project and go from there.

Once all of these values are specified, press Finish to create the project.

What Just Happened?

NetBeans did a lot of stuff behind the scenes. I think it’s important to take a quick look to see what that process just gave us. Below is a screenshot of the contents of the directory I used in the Project Location field during the project creation wizard.

Ignoring my other projects, notice the highlighted HelloWorld directory which was created by NetBeans (again, the directory name was taken from the Project Name in the wizard). NetBeans creates three additional directories inside of the project directory.

• nbproject – Contains the files NetBeans needs to store information about the project. This can be safely ignored; you won’t need to directly interact with these files. However, keep in mind that directory and its contents are only needed by NetBeans; don’t get confused and think these are part of your project (so they don’t need to be submitted to your professor).
• src – The directory name “src” is the typical abbreviation for “source code” and is where the actual code for your project will go. NetBeans will automatically put most classes in here for you, but it’s important to know where they ultimately end up (I’ll come back to this later when we create a class).
• test – This is another typical convention seen in many projects. Often, code that is used to automatically test your application is kept separate from the product code itself (don’t mistake that to mean it is any less important). Testing is a huge topic so I won’t go into any more detail here.

The other two files shouldn’t need to be edited either. The short answer is that NetBeans will use them to compile and run your project, so don’t touch them.

Now What?

Once the project is created, you’re dropped to the main NetBeans screen. The next steps will be to create a class, compile, and run the main method from inside of NetBeans. I’ll cover all of that in the next post.

1
2
3
4
5
6
7
8
9

try {
    String line = input.readLine();
    while (line != null) {
        line = input.readLine();
    }
}
catch (IOException ioe) {
    logger.debug("IOException...really need better handling here");
}

Everyone, at one point or another, is guilty for just swallowing an exception. Java tends to be a bit trigger happy with its checked exceptions (especially in the IO packages), so it’s inevitable to be in a position of having to deal with an exception that admittedly will probably not happen while trying to get something else accomplished.

The nice part is that I’m cleaning this up and actually providing the better handling. The cool part is that I’m using code I wrote for CodeTurtle to do it.

I’m totally addicted to the Java preferences framework.

For a while, I’ve wanted to add user preferences to CodeTurtle. My motivation was less letting the user explicitly set certain values and more about adding in polish to the UI. For instance, I wanted to remember the last position and size of the UI if the user moved it (rather than always starting maximized or something like that). Little things like that are somewhat taken for granted until you use a UI that doesn’t have them, at which time phrases like “This sucks” tends to come out. Besides, it seemed like a fun challenge.

I thought I was going to have to choose between using a simple key/value pair serialized to disk or actually adding in an XML framework for more flexibility and dealing with that headache (or some other unholy third option). What I found out was how little I actually knew. The Java preferences framework gives you both for pretty much free.

Java will keep track of storing the preferences in wherever it makes sense based on the native operating system (for instance, they are stored in a directory named .java in the user’s home directory on Linux). The format is XML, but it’s actually not necessary to know that since I don’t have to do squat to actually interact with it.

To load the preferences, it’s a one line call:

Preferences preferences = Preferences.userNodeForPackage(this.getClass());

After that, it’s simple getters to get your values. The Preferences object even has some really nice polish on the API letting you use type specific getters (getString, getBoolean, etc) and specify a default value. Setting values uses a put notation that functions like the Map interface.

int windowWidth = preferences.getInt("window.width", 800);
...
preferences.putInt("window.width", frame.getWidth());

That’s it. That’s all you need to cover reading/writing the file, determining the proper home directory location, and serializing/deserializing the XML store of the data. My daughter could write code to use this if she could stop drooling long enough to not short circuit the keyboard.

You technically don’t even have to worry about saving, it will periodically do that for you. However, if you want to explicitly trigger a save, simply call the flush() method on the preferences object.

I even built in a command line option to CodeTurtle to clear the user preferences, which is in itself a simple call:

preferences.removeNode();

I was happy to see that my design of having a central data manager passed throughout the GUI came in handy here as I was able to stuff the preferences object into it and access it from virtually anywhere else in the UI. At that point, it was just a matter of figuring out what I wanted to store. In the beginning it was things like the window placement, window size, and tab placement. Tonight I decided to add a flag indicating if it’s the first time the user is running CodeTurtle. If it is, I enter a bit of a “demo mode” where the sample project included with the CodeTurtle distribution is automatically loaded to more easily show off its complete awesomeness.

I still have other (reasonable) ideas on things I want to stuff into user preferences. Rather than requiring an environment variable to indicate the compiler path (i.e. TURTLE_JDK_HOME, JAVA_HOME), I’d like to move that to the user preferences to make it easier to see where the value came from. The real challenge at this point is trying to not abuse this new found power and stuff every imaginable value into it.

My annoyingly over-engineered (and pretty much completely unnecessary) wrapper on top of the Java preferences framework can be found in CodeTurtle’s SourceForge repository.