Über Conf

Mastering Node

Mike Girouard — Mon, 06 Sep 2010 13:00:21 CDT

@codepo8 was kind enough to share a link to Mastering Node, an open source eBook on NodeJS.

It’s still a work in progress, but it’s the most complete I’ve seen so far. There’s no formal table of contents, but if you peek at the Makefile, you can get a clear idea on the topics covered so far:

Installing Node
CommonJS Module System
Globals
Events
Buffers
Streams
File System
TCP
HTTP
Connect
Express
Testing
Deployment

The easiest thing to to is to clone the repo and build the book (htmldoc req’d) that way you always have the latest and greatest. If you’re lazy, just browse the repo’s .md files or download the PDF that is already built.

via Mastering Node and @codepo8

Share this post

Story of my life…

Mike Girouard — Mon, 06 Sep 2010 11:00:20 CDT

via Toothpaste For Dinner – ARCHIVE: Aug 2010.

Share this post

The Agile Guerilla Series

Matt Stine — Mon, 06 Sep 2010 08:00:22 CDT

I recently completed a series of articles for Agile Zone entitled “The Agile Guerilla.” Those of you that have seen me on the No Fluff Just Stuff tour this year may recognize a talk by the same name. They are one and the same concept: my attempt to reach the masses with strategies for introducing change, specifically moving to agility, into organizations from the grassroots level.

Here’s a list of the complete set of articles for your convenience!

First place [Flickr]

Aaron Gustafson — Sun, 05 Sep 2010 16:00:15 CDT

Aaron Gustafson posted a photo:

[Flickr]

Aaron Gustafson — Sun, 05 Sep 2010 13:00:16 CDT

Aaron Gustafson posted a photo:

What has Maven ever done for us?

John Smart — Sun, 05 Sep 2010 11:00:32 CDT

Notes from the People's Popular Anti-Maven Front of Java General Meeting

REG: All these years. Maven has bled us dry with convoluted XML files, forced us to respect the Maven way, and made us download the internet at every build. And what has Maven ever given us in return?!

JAVA COMMANDO #1: Standard directory structures?

REG: What?

JAVA COMMANDO #1: Standard directory structures.

REG: Oh. Yeah, yeah. It did give us that. Uh, that's true. Yeah.

JAVA COMMANDO #2: And common build targets across projects. Remember how hard it use to be with Ant, to figure out how to build a new project?

REG: Yeah. All right. I'll grant you, standard directory structures and common build targets are two things that Maven has done well.

JAVA COMMANDO #2: And Declarative Dependency Management.

REG: Yeah. Well, obviously, Declarative Dependency Management. I mean, Declarative Dependency Management goes without saying, doesn't it - everyone wants to do that now. But apart from Standard Directory Structures, common build targets, and Declarative Dependency Management--

JAVA COMMANDO #3: Common artifact naming conventions?

JAVA COMMANDO #1: Code quality reporting

JAVA COMMANDO #2: Yeah, Sonar

REG: Yeah, yeah. All right. Fair enough.

JAVA COMMANDO #4: Enterprise Repositories?

JAVA COMMANDO #2: Yeah, you can actually publish your JAR files without using email, now. They're the ones who came up with that.

REG: All right, but apart from Standard Directory Structures, common build targets, and Declarative Dependency Management, a common artifact naming convention, code quality reporting, Sonar, Enterprise Repositories, what has Maven ever done for us?

JAVA COMMANDO #1: Groovy pom files?

REG: Oh. Shut up!

Check out the original version here.

Unofficial IRC channel for WebSphere eXtreme Scale

Billy Newport — Sun, 05 Sep 2010 08:00:22 CDT

I'm making an IRC channel on the IRC server ircnet.eversible.com called #ibmwxs

I'll be hanging there as often as I can and hopefully you to.

PrettyFaces 3.1.0 released: URL-rewriting for Servlet & JSF

Lincoln Baxter III — Sat, 04 Sep 2010 16:00:23 CDT

» Get PrettyFaces!

Features & Enhancements:

Introducing URL mapping configuration with annotations (tutorial + docs)
Added path and query-parameter validation wth managed bean methods (#50 + r353)
Added support for JSF2 redirects using ExternalContext (r305)
Added support for arrays as query parameters (r278)

Special thanks to Christian Kaltepoth for his incredible annotations configuration system, and for fixing more bugs than any other project member over the past 3 months!

Regression impact:

The URL query string is now included in rewrite-rules; this allows for finer control of the rewriting engine (Any prior rewrite rules should be revised and re-tested)
PrettyContext.getCurrentURL() has been replaced with PrettyContext.getRequestURL() and PrettyContext.getRequestQueryString()

Bugfixes:

Resolved Mojarra warning “Request path ‘/faces/url.xhtml’ begins with one or more occurrences of the FacesServlet prefix path mapping ‘/faces’.” when using path mapping (#43 + r379)
Resolved Deployment warning on Geronimo (#58 + r364)
URL Path Expressions now match correctly when more than one expression is used between path segments (r362)
Resolved ClassNotFoundException with JSF 1.2 on JBoss6 (#54 + r360)
Resolved failed deployment due to ClassNotFoundException on Geronimo (#59 + r369)

RichFaces 4.0 M2 is now available

Max Katz — Sat, 04 Sep 2010 13:00:25 CDT

RichFaces 4 is one more milestone closer to GA. This week JBoss and Exadel teams have released RichFaces 4 Milestone 2. This milestone includes:

New components: accordion, autocomplete, inplaceInput, and inputNumberSlider
Large scale stabilization to our core and CDK modules.
The RichFaces Showcase Demo now includes all the components
Support for cloud deployment is coming

For more details, head to this post by Jay Balunas. There is more information on Milestone 3 plans as well as final release.

If your team considering RichFaces 4, to get them up to speed faster, consider on-site RichFaces training or 1-day RichFaces 3 to 4 workshop.

Two other RichFaces events coming up:

Workshop: RichFaces 4 workshop at Herbstcampus in Nuremberg
Webinar: Ajax Applications with JSF 2 and the New RichFaces 4

Unofficial IRC channel for WebSphere eXtreme Scale

Billy Newport — Sat, 04 Sep 2010 11:00:19 CDT

I'm making an IRC channel on the IRC server ircnet.eversible.com called #ibmwxs

I'll be hanging there as often as I can and hopefully you to.

9 Useful PHP Functions and Features You Need to Know

Mike Girouard — Sat, 04 Sep 2010 08:00:21 CDT

Nettuts+ a good one today: 9 Useful PHP Functions and Features You Need to Know.

A few good ones are on there which I didn’t know about like glob(), scandir(), gzcompress()/gzuncompress() and I’m surprised that I never knew about register_shutdown_function().

Share this post

A Quick Intro to mongosniff

Mike Girouard — Fri, 03 Sep 2010 16:00:17 CDT

Kristina (MongoDB’s author of the PHP and Perl driver) has published a quick and excellent introduction to mongosniff.

Writing an application on top of a framework on top of a driver on top of the database is a bit like playing telephone: you say “insert foo” and the database says “purple monkey dishwasher.” mongosniff lets you see exactly what the database is hearing and saying.

I wasn’t even aware of this little gem of a tool. I’ve been stuck in a few situations where I’ve often wondered what was going on in the background.

via A Quick Intro to mongosniff.

Share this post

Sharding with Hibernate

Andrew Glover — Fri, 03 Sep 2010 13:00:26 CDT

As I’ve pointed out before, sharding isn’t for everyone, but it’s one way that relational systems can meet the demands of huge data. For some shops, sharding means being able to keep a trusted database like MySQL in place without sacrificing data scalability or system performance. In this installment of the Java development 2.0 series, dubbed “Sharding with Hibernate Shards” find out when sharding works, and when it doesn’t, and then get your hands busy sharding a simple Hibernate & Spring application capable of handling terabytes of data.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Indieconf

Mike Girouard — Fri, 03 Sep 2010 11:00:30 CDT

indieconf – the independent and web freelancer conference looks like a really awesome conference. If you’re a participant in the conference season (either as a speaker or attendee) this is one to add to your list.

There’s pretty much no reason to not go: It’s one day, on a Saturday, and only $99.

So far the sessions include:

Legal Issues in Software Development
Pricing Your Services
Marketing Through Publishing
Top 10 Misconceptions of Software Freelancing
Marketing Yourself as a Freelancer on an Online Community
Driving Yourself to Success
Retooling Your Workflow (Or: Git + Tickets = Happiness)

… and it appears that their CFP is still open (also very tempting).

Share this post

Links for 2010-09-02 [del.icio.us]

Aaron Gustafson — Fri, 03 Sep 2010 08:00:33 CDT

GabberTalk
Need chat? Check this out.
CoffeeScript
An interesting abstraction of JavaScript.
Jade
Templating for node.js

Ouch [Flickr]

Aaron Gustafson — Thu, 02 Sep 2010 16:00:12 CDT

Aaron Gustafson posted a photo:

I don't unit test my classes

John Smart — Thu, 02 Sep 2010 13:00:15 CDT

I don't unit test my classes. I don't even unit-test my methods. You'll be hard-put to find the word "test" in my source code. And I never, ever create a new JUnit Test Case Eclipse.

I prefer to test how my application behaves. And I find it makes a huge difference.

So how does that work? Well, I usually start off with a user story. Or, more precisely, with an acceptance test criteria. But I could have started with detailed specifications - it doesn't really matter. The point is, I'm starting with some requirements - in other words, a description of what my code is supposed to do.

In practice, I will usually try to automate the acceptance criteria. Maybe a high-level test that steps through the whole user story to give a picture of where we are going. Automating the high-level test criteria, even incompletely, is a great idea, as it gives you a set of goal posts, an idea of what you are supposed to achieve for this requirement. It also forces you to think about the requirements in very concrete terms. I'll elaborate on this approach (which is known as Acceptance-Test-Driven-Development, or ATDD) in another article. I won't focus on domain modeling, or domain-driven-development, or high-level architecture workshops, or any other of the numerous technical activities that might end up going between the high-level requirements and the actual coding - all these have their place, but I don't want to discuss them here. In this article, I want to focus on the more low-level tests.

I start off the actual coding by creating a new test class. But I don't call this class AccountTest or GizmoTest, or any other name with the word "Test" in it for that matter. I prefer to name my test after the feature I am trying to implement: WhenAnAccountManagerConsultsTheClientDetails WhenAClientTransfersMoneyBetweenAccounts, or WhenTheGizmoSpinsInAClockwiseDirection. I might need several such test classes to fully explore the feature I'm working on. And I might need to drill down, later on, into more technical details. But the essential approach is this: it's all about providing context.

This is by no means just a formality. Naming the class well forces me to think about the feature I'm trying to implement. And it's harder than it sounds. But it gets me thinking about what the application will do in practice, and is the first step in the detailed design process.

Next, I drill down into the details. What exactly should the code do? I typically express this in the form sentence-like structures, very similar to the acceptance criteria. If I need to, I'll add some extra ones to clarify the requirements further. This is pretty standard TDD-stuff - nothing fancy here. The important thing is to make sure each one contains a context, an action and an expected outcome:

When the account manager clicks on the client name the client details page should be displayed
When the source account has insufficient funds, the transfer is refused and no money is deducted from the source account
When the gizmo reaches 10 RPS, the red flashing light goes on.
...

Sometimes the name of the class acts as a context, so you can get away with just the action and the expected outcome. But there should be an action and an expected outcome expressed somewhere.

Each of these sentences becomes a test. The exact form of the test will depend on your project. For Java projects, JUnit 4 will work fine, as will nUnit for .Net code. For the higher-level tests I am more inclined to use a dedicated BDD framework such as easyb or JBehave. For Groovy and Grails, Spock is a great developer-focused BDD tool. And Ruby developers are very fond of RSpec and Cucumber. But even if you don't want to open a new tool box, you can still take advantage of this approach - just pay attention to your test names!

In JUnit 4 code, for example, the tests might look something like this: public void whenTheUserClicksOnTheClientNameTheDetailsPageShouldAppear(){ ... } or public void whenTheSourceAccountHasInsufficientFundsTheTranferIsNotDone() { ... }

And now that I have a good idea about what I am supposed to be coding, I can start to think about classes and methods. Indeed, how could I start to code, if I don't understand the problem?

With a bit of care, this approach also give you a clean, well-organized, and above all working set of examples covering in detail how the different features that make up the application have been implemented, and how classes used to build the application are meant to be used. The class names and the method names read like a narrative. All you need to do is to organize them into sensible packages (for example, by feature).

So I'm not actually testing my classes, or my methods. I'm testing the behaviour of my application - I just happen to be doing it by exercising classes and method calls. And the same approach applies at any level - I could be implementing web tests using page objects, or writing a low-level technical module. The same principles apply.

This approach is of course not new - it's known as Behaviour-Driven Development, and there are some great tools out there to help you formalize the process. No matter what tool or language you are using, I would recommend 'The Rspec Book', by Dan North and friends, as a good introduction to the general approach.

Come to Relevance and Be Excellent

Stuart Halloway — Thu, 02 Sep 2010 11:00:20 CDT

Earlier, we posted that we were seeking some new PMs for the Relevance team. At that time, I mentioned that we were always looking for great technical folk as well. I think that deserves its own post.

Our team is growing pretty fast. Our combination of technology platforms and deep devotion to the people side of software is resonating really well with our customers and we want to encourage and enable that growth. So what are we looking for? I'm glad you asked.

Are you excellent at Ruby and/or Clojure? Can you work sitting next to somebody who is at least as smart as you, pairing on solutions to wicked problems? Do you want to work on open source or community projects 20% of the time? Can you jump back and forth between small apps for early-stage startups and giant systems for Fortune 100 companies? How good are you at ping pong? Can you demonstrate a history of having an impact on the projects you contribute to? Do you practice TDD and have strong opinions about testing frameworks (we have an ongoing war over Cucumber here, and we need more combatants)? Have you read Cryptonomicon, Daemon or The Black Swan? Do you like to speak at conferences or write awesome blog posts about cool technology? Are you comfortable getting direct feedback about your work? How many of the founders of GitHub can you name?

If you found yourself in the questions above, we want to talk with you. We're looking for full-time or contract technologists. We especially want people who can work in our Durham office, or who live in DC. Come be part of something growing, special and fun.

Drop us a line at jobs@thinkrelevance.com.

Exadel Tiggr mockups – dynamic widgets

Max Katz — Thu, 02 Sep 2010 08:00:23 CDT

One of the neat features in Exadel Tiggr mockup creation and sharing tool is dynamic widgets. Let me explain. Let’s say you have a tab panel with three tabs. Different content goes into the three tabs. When designing mockups, there is no simple way to show what content/widgets go into the first tab, the second and so on. With Tiggr is very simple because the tab widget is dynamic. In other words, you can click on the tab and switch between them. This way you can place different content into the tabs during design as in real application.

First tab:

Second tab:

Third tab:

To edit tab label, just double-click on the text. And, to add/remove tabs, click on the tab and invoke the context-menu as shown:

MongoDB and CouchDB: vastly different queries

Andrew Glover — Wed, 01 Sep 2010 16:00:15 CDT

Both MongoDB and CouchDB are document-oriented datastores. They both work with JSON documents. They both are usually thrown into the NoSQL bucket. They’re both hip. But that’s where the similarities, for the most part, stop.

When it comes to queries, both couldn’t be any more different. CouchDB requires pre-defined views (which are essentially JavaScript MapReduce functions) and MongoDB supports dynamic-queries (basically what you’re used to with normal RDBMS ad-hoc SQL queries). What’s more, when it comes to queries, CouchDB’s API is RESTful, while MongoDB’s API is more native — that is, you essentially issue a query using a driver in the code of your choice.

For example, with CouchDB, in order to insert some data, I can use a tool like Groovy’s RESTClient and issue a RESTful post like so:

import static groovyx.net.http.ContentType.JSON
import groovyx.net.http.RESTClient

def client = new RESTClient("http://localhost:5498/")
response = client.put(path: "parking_tickets/1234334325",
  contentType: JSON,
  requestContentType:  JSON,
  body: [officer: "Robert Grey",
         location: "199 Castle Dr",
         vehicle_plate: "New York 77777",
         offense: "Parked in no parking zone",
         date: "2010/07/31"])

Note, in this case, I have to delineate a ID for this parking ticket (1234334325) (I can, incidentally, ask CouchDB for a UUID too by issuing an HTTP GET to the /_uuids path).

If I wish to find all tickets issued by Officer Grey, for example, I must define a view. Views are simply URLs that execute JavaScript MapReduce functions. Accordingly, I can quickly code a function to grab any document whose officer property is “Robert Grey” like so:

function(doc) {
  if(doc.officer == "Robert Grey"){
    emit(null, doc);
  }
}

I have to give this view a name; consequently, when I issue an HTPP GET request to that view’s name, I can expect at least one document:

response = client.get(path: "parking_tickets/_view/by_name/officer_grey",
        contentType: JSON, requestContentType: JSON)

assert response.data.total_rows == 1
response.data.rows.each{
   assert it.value.officer == "Robert Grey"
}

In summary, with CouchDB, I can’t quickly issue an ad-hoc RESTful call to obtain some bit of information — I must first define a query (aka view) and then expose it to the outside world. In contrast, MongoDB works much like you’ve been used to with normal databases: you can query for what ever your heart desires at runtime.

For example, I can add the same instance of a parking ticket using MongoDB’s native Java driver (there are better options for working with MongoDB, by the way) like so:

DBCollection coll = db.getCollection("parking_tickets");
BasicDBObject doc = new BasicDBObject();

doc.put("officer", "Robert Grey");
doc.put("location", "199 Castle Dr");
doc.put("vehicle_plate", "New York 77777");
//...
coll.insert(doc);

I can subsequently find any ticket issued by Officer Robert Smith by simply issuing a query on the officer property like so:

BasicDBObject query = new BasicDBObject();
query.put("officer", "Robert Smith");
DBCursor cur = coll.find(query);
 while (cur.hasNext()) {
   System.out.println(cur.next());
 }

Thus, while both document-oriented datastores have some similarities, then it comes to querying, they are vastly different. CouchDB requires the usage of MapReduce while MongoDB allows for more dynamically oriented queries (MongoDB also supports MapReduce). Can you dig it?

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.