Publish! (JavaZone 2012)

Lightning talk from JavaZone 2012. As promised here are the notes, with pointers to more information.

Links to more information

Google code hosting: Getting started.

Example pom for Google hosted projects.

GitHub (getting started on front page).

Example project / pom for GitHub hosted projects.

Sonatype OSS Repository Hosting Service: Usage guide.
Blog post with more details than the above (but not up to date)
Guide from Apache.

About Open Source Licenses.

Script

Welcome to this talk titled Publish! It is about publishing an Open Source project.
I will try to convince you that this is not hard to do, and that you stand to benefit from doing such a thing.

My name is Tommy Skodje
I work for the consultancy Antares, we have a stand out in the hall.
I have programmed for some years now, but only yesteryear I opensourced my first project, test-data-control. A tool for exporting / importing data from database.
That was a good experience, and I want to share this with you.

First version

Now for the 9 steps I took to publish the project.

I created the project on Google Code Hosting and used project information to fill in Jira ticket on Sonatype OSS Repository Hosting Service

That´s how I asked Sonatype to create Maven repositories for me.

There was not much to the creation forms - Googles is the big one with 6 fields (you have to select vcs and license).

Jira ticket needs the same information, plus urls to the project hosting, and groupId

I got a reply on the ticket, asking me to change groupId.

So I did, and the next day my ticket was resolved and I could code and deploy my project to Maven repositories on Sonatype.
With this formalities around the project were done.

Releasing

After a while I was ready to stage a release - I did it using normal maven release procedure, which put my artifacts into Sonatypes Nexus.

I then logged in to Sonatypes Nexus, found my repository and pushed 4 buttons to release my staging repository.

The first time I released I commented my Jira ticket to let them know they should verify my project and turn on Maven Central synchronization if OK.

The next day Jira mailed me the reply and I found my artifacts in Maven Central.

Central Sync requirements

Before I could stage the first release, my pom needed at least the 12 lines on the left.
Javadoc and source artifacts has to be produced.
Artifacts signed using GPG.
Sonatype helps by providing oss-parent pom that defines tasks related to releasing, and they give nice instructions about how to install and set up GPG signing.
Project does not need to be Mavenized, but it needs a pom.

Licensing

I chose Apache v2. Applying it is easy - added LICENSE and NOTICE files on top level, and comment all source files.
NOTICE is for honoring inclusions - now that I published I needed to track licensing of libraries and code I include.

Subsequent versions

After the first release, it got a lot easier.

I should have

Project was almost coded ready when I took out the Jira ticket.
Then I refactored package structure and pasted in Copyright all over.
And then a complete rewrite in Scala…
I would have been better off starting with the formalities and no code.

I chose a poor name - what a pity - project name is final. The other stuff is mutable.

Why

Curiousity and ambition got me started.

I wanted to learn more about opensourcing, and show off me and Antares.

But I soon realized that Open Source programming differs from inhouse-projects in many respects.
Theres was no restrictive firewall or policies. I could cod and commit whenever I had internet. I even submitted work from my iPhone.
Schedules and pressures were not the same either. I felt more pressure to code cleanly than quickly.

And with myself at the helm I could pursue my own agenda.

So I ported it to Scala.
I had just read the book and wanted some practice.
Clients would not mind implementation details.

That was a big job, I have done several other small stunts.

I now want to make a command-line utility of it that interpretes an external DSL.
There was a nice article in PragPub magazine that I am keen to follow up on, and I have also read too much about DSLs that I haven´t practiced yet.
And both should be a nice fit here.

I rarely get to do such things otherwise.

A Young Girl Reading, Jean-Honoré Fragonard

Normally, on daytime projects, I stop and do research when there is a need.

Now, I can read stuff from the stream that may fit nicely, or that I really would like to try.
And I can! Even if the project was «done» 2 months ago…

Having a side project facilitated deeper learning.

I tried to practice TDD from the start.
Many a time I gave thanks to my former self for doing that! Automated tests made it a lot easier to code a little now and then.
And also release quick changes that I needed on my daytime project.

That helped TDD click with me!

Going public was scary.
More than once I pondered my craftsmanship.
I did more beautifying, simplification, refactoring and testing than earlier.
Slowed me first, but I improved.
One day at work I realized I could do it, efficiently and confidently.
Publishing my work has driven me to evolve.

El Afilador, Francisco de Goya

Being my own client has been wonderful.
I could sharpen my own tool and skills at the same time.
API cumbersome or lacking? I improved it. More usable with each reuse.

Many revisits makes this feel like growing SW.
And I gradually learned more about design, documentation and testing.
Also because I forget stuff between iterations, and I can see better when I start with fresh eyes.

Thank you

I really enjoy the project, tinkering with it, making it better every now and then, and learning by practicing. I would like to say thank you to Sonatype, Google, GitHub and all the other hosting sites for making this so convenient. And to Øystein Pettersen at Evry for telling me where I could get synchronization to Maven Central.

JavaZone: introducing Apache Wicket

Presentation from JavaZone 2011: http://javazone.no/incogito10/events/JavaZone%202011/sessions/Introducing%20Apache%20Wicket

Video posted to http://vimeo.com/28791557

Notes:

7 years old framework, Wicket 1.5 just released

Component oriented, using just java+html

Used by: AdScale, WalMart, MeetMoi, fabulous40...

Just html: elements linked to wicket by attributes: <p wicket:id="foo">, no imperative markup in view.

Just Java: no logic in markup, Components are POJOs, No xml

Components: Manipulate markup, Render content, Receive events (onClick)

Models: data to / from Components, transform data

Behaviors: Decorator / Adapter for Component, manipulate markup of Component, can receive events (onClick), Add Ajax unctionality to Components

Wicket projects: Apache Wicket (core, integration to Spring...), Wicket stuff (components), Seam for Apache Wicket, WiQuery (jQuery), Leg before Wicket (archetypes), Apache Isis (DDD framework), Jolira Tools, Visural Wicket (components)...

Quick start: use Maven, http://wicket.apache.org/start/quickstart.html

Some examples: Hello World, click-counter, sign-up

Navigation: Overview and some detail on: External link, Bookmarkable link, Action

Validators: Overview, simple example and list of provided validators

jQuery integration: WiQuery overview and example

JqZoom: Example, zoom on image, how to integrate

Development / Deployment mode: List differences and show some features

WicketTester: Tests components, UI, Ajax, without starting server, runs in IDE, ant, maven

New in 1.5: Html5 input types, component event bus, some new components, improved internals, simpler request cycle, and more

Component event bus: pre/post example

Wicket 6: next version, preliminary list of features. Shorter release cycle.

Q&A: How do components handle history button? Do you endorse Wicket WebBeans for rapid development?

OpenSourcing

I recently published my project, test-data-control, on googlecode, and want to jot down some stuff before I forget.

I wanted a subversion-enabled hosting, and chose Google because I have the impression they're fast and convenient pluss I like their philosophy.

At first, I found that I had to choose a license and structure the project so that it goes nicely into Google. I had a little ponder, but chose Apache license to go easy.

Filling in the form was straight forward, but I should have drafted it before I started on the web, these fields were filed:

Project name, summary, description. version control system, license and label(s)

Gotcha: Project name and version control system can not be changed later.

 

I then proceeded to apply for Sonatype OSS Maven Repository access, so that other projects can get to this library (they even push to Maven Central). Following the Usage guide, I found I needed some more stuff, mainly in pom, and should change my groupId.

Wisdom: I should have known what it took before I first comitted project to Google, but it wasn't a big sweat.

 

All in all, the application processes were smooth and pleasan. Google project hosting was available immediately, Sonatype OSS Maven Repository access was ready for me over night (I'm on European timezone, so I guess they work when I sleep, which is a nice thought).

 

I was also surprised to experience a period of euphoria, having published something for the first time. I'd say it's worth the extra effort of preparing it and publishing it just for that feeling. Another nice thing I have experienced since I started sharing my ambitions with coworkers is that my status have increased so that I'm being used as an authority and pulled into discussions about related issues. I also get all kinds of tips now that they know I'm working on this thing. It feels like the project is starting to pull it's own weight.

The authority stamp feels a bit premature, because I feel that I need to produce a fully working system and prove it before I can claim that. I'm only glad that I did a fair bit of literature research before I came to this, so I'm usually able to answer and give some advise without making a fool of myself.

Meetup om testing i Framsia

Det handler om å kjøre (all) koden din, så ofte som mulig, med så gode tilbakemeldinger som mulig.

Buster.js ble presentert.

OperaDriver og ChromeDriver kommer sannsynligvis til Selenium 2 beta 4

Mange tester for html5 er skrevet i WebDriver

Doing SW Architecture / Research Project

When researching a new tool or a framework API for use I find myself getting tired or bored after spending time doing work that will not be directly productive, and previously I have made rush decisions or didn't "go all the way", thinking that "barely sufficient" = enough.

The other day, I started thinking that different ways of revisiting such projects should add real value. preferably, there should be (at least) 1 more person with a fresh attitude who can continue from where I left, and/or do:

• review / inspection
• come up with new ideas
• bring more involvement / acceptance from the whole group

If it is too hard to get 1 more person, it may be wise to simulate him by taking a break from this project and revisiting it later.

 

SiteMesh

SiteMesh

From OpenSymphony.

Code can be downloaded here.

 

Overview

Web-page layout and decoration.

Aids generating consistent look/feel, navigation and layout scheme.

Can include other pages (server-side include).

J2EE, but can be used outside as well (PHP, CGI...).

Extensible.

 

 

Setting up

 

pom.xml:

<dependency>

<groupId>opensymphony</groupId>

<artifactId>sitemesh</artifactId>

<version>2.4.2</version>

</dependency>

web.xml:

<filter>

<filter-name>sitemesh</filter-name>

<filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>sitemesh</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>sitemesh</filter-name>

<url-pattern>*.do</url-pattern>

</filter-mapping>

<jsp-config>

<taglib>

<taglib-uri>sitemesh-page</taglib-uri>

<taglib-location>/WEB-INF/sitemesh-page.tld</taglib-location>

</taglib>

<taglib>

<taglib-uri>sitemesh-decorator</taglib-uri>

<taglib-location>/WEB-INF/sitemesh-decorator.tld</taglib-location>

</taglib>

</jsp-config>

Copy in mentioned files (tld)

decorators.xml:

<decoratorsdefaultdir="/decorators">

<decorator name="main" page="main.jsp">

<pattern>*</pattern>

</decorator>

 

<decorator name="printable" page="printable.jsp"/>

</decorators>

 

Default logic to determine what decorator to apply, first match:

1. Meta decorator tag in page
2. Don't apply a decorator to frame set
3. Url with printable=true parameter (If so, use the printable decorator.)
4. Does the page specifically request a decorator by the decorator file name?
5. Does the page url match a pattern in the decorators.xml file?

Can be overridden.

Decorator example

<%@taglib uri="sitemesh-decorator" prefix="decorator"%>

 

<decorator:usePageid="myPage"/>

<html>

<head>

<title>SiteMesh main - <decorator:title default="Welcome!"/></title>

 

<decorator:head/>

</head>

 

<body>

<h1>SiteMesh main <decorator:title default="Welcome!"/></h1>

<h3><a

href="mailto:<decorator:getProperty property="meta.author"

default="staff@example.com"/>">

<decorator:getProperty property="meta.author"

default="staff@example.com"/>

</a>

</h3>

<hr/>

 

<decorator:body/>

 

<p><small> (<a href="?printable=true">printable version</a>)</small></p>

</body>

</html>

Mac mods

For MacBook: http://www.extremetech.com/article2/0,2845,2363244,00.asp.

For Mac mini:  http://www.applefritter.com/Mac_Mini_Take_Apart_Guide.