Java URL builder 1.1 release

I've just released the version 1.1 of my Java URL builder to Maven.

Project: https://github.com/mikaelhg/urlbuilder

UrlBuilder.fromString("http://www.google.com/")
    .addParameter("q", "charlie brown")
    .toString() == "http://www.google.com/?q=charlie+brown"

UrlBuilder.fromString("http://foo/h%F6pl%E4", "ISO-8859-1")
    .encodeAs("UTF-8")
    .toString() == "http://foo/h%C3%B6pl%C3%A4"

final UrlBuilder ub1 = UrlBuilder.fromEmpty()
    .withProtocol("http")
    .withHost("www.example.com")
    .withPath("/")
    .addParameter("foo", "bar");

final java.net.URI uri1 = ub1.toUri();

try {
    final java.net.URI uri2 = ub1.toUriWithException();
} catch (java.net.URISyntaxException ex) {
    // handle the exception
}

final java.net.URL url1 = ub1.toUrl();

try {
    final java.net.URL url2 = ub1.toUrlWithException();
} catch (java.net.MalformedURLException ex) {
    // handle the exception
}

The basics of professional software development

I was asked to break down a top-level description of my following description of how to describe the part of the software development profession one should optimize for.

"Ethical professional developers optimize for business results per unit of resources over product or project lifecycles, balanced risk profiles over project portfolios, and the ablity to scale investment into a given project both up and down as the business environment changes."

Let's break this down.

Ethics

The virtue of a professional acting ethically is that this allows for trust in working relations between colleagues and organizations, which in turn makes working together significantly more efficient, as there is significantly less need to verify and control. The profession of software development has plenty of in-house codes of conduct, as well as the codified ACM "Software Engineering Code of Ethics and Professional Practice".

Many of the everyday ethical questions break down to the form: should I do A which is best for me, B which is best for my employer, or C which is best for the client. Very rarely you add D, best for our society, when C is clearly detrimental to the society. Unless D is relevant, you should pick C, and you're obligated to look at the problem from the broadest point of view your client consents to provide you with.

Product or project lifecycle

When you're considering a product or a project, it's tempting to care only to the extent you're personally involved with it, and wash your hands of the rest. That's not consistent with the aforementioned professional ethics, though. When making decisions, you must consider the costs and benefits of your choices over the whole lifecycle.

A lifecycle means simply the time and space during which the project is being developed. It's also strongly connected to the business motivation that birthed the project in the first place, and through that, to the adjacent businesses and offerings, the marketplace in which it operates, and its competitors.

Optimizing for business results per unit of resources

If you're paid to develop software, it's extremely likely that you're getting paid with the hope that you'll deliver business results. Those might be the capability to serve new customers, serve them better, serve them cheaper, serve more of them, serve them with a varying quality of service, enlarge market share, retarget market share, shorten supply lines, simplify them, work around risks, work around legal barriers, or anything of the sort.

It's very important to understand what business results you're expected to deliver, and how the company and its marketplace operates in those areas. As a professional, you're also expected to communicate a clear enough understanding of how exactly should resources be invested in your area, to get the best results possible. To be able to deliver that, you must understand the nature of those resources, and the process through which they are turned into results. In other words, how people of your profession and adjacent professions work, what happens in people's heads in general, what must be done to get your specific group of individuals to perform together, which skills and how much throughput is required to achieve your objectives, and how to get your hands on those.

Resources are, in our profession, mainly people, but also servers, personal desktops, licenses, enough throughput in corporate processes so that your people can work efficiently, and most importantly, correctly budgeted cash so that you can pay your people, as well as acquire outside expertise if it's needed. You need to understand how capex and opex budgeting works, so that you won't be caught with your pants down with only the kind of money you can spend on bailing water out of the boat, and no cash which you can spend to fix the giant leak in the side.

It's also easy to forget that from your client's standpoint, often the most important costs associated with your project aren't the development costs, but the cost of the its normal daily use by people, over its lifecycle. When thinking of where to spend your development resources, consider that.

Balanced risk profiles over project portfolios

Risks and uncertainties concern the probability of the shit hitting a fan in the future, as well as its color and consistency. Every choice carries its own risks. Some alternatives have been tried and tested, and you can guess what's going to happen with more certainty than with other choices.

This is a common and well-known phenomenon. If you're an expert in your field, and provide advice to people concerning your profession, you are required to have a reasonable understanding of the risks your recommendations carry, and communicate that information to your client, by all professional codes of ethics I'm familiar with. Especially in the cases where you're either unaware of the risks, or you're aware of significant unknowns.

The flipside of risks is that you can mitigate them by planning what to do if the shit hits the fan in a certain way, and provisioning for specific eventualities. A common way to handle software risks is to invest in deep in-house expertise for specific aspects of specific technologies, acquire quick-response consulting contracts for them, or to over-provision server resources. This costs a lot of resources.

In balancing risk profiles over project portfolios, you make technology or process choices which are common to many projects. That way you achieve more with the same risk mitigation investment, or you're able to mitigate a significantly larger group of risks and uncertainties.

This very seldom happens by chance - you have to understand the principles and apply this understanding when making technical choices in projects.

Scaling project investment up and down

When you succeed and your customers are unusually excited about your product, you want to be able to invest more in its development.

If there's, say, an economic downturn, you might want to turn down the heat on your product, and invest less in its development.

Again, if you leave these abilities to chance, it's very likely that your people will get very stressed out when new people are hired, or some of the existing people are moved to other projects, and they have to cope with the change.

However, if you're aware of the fact that conditions often change, you can invest in documentation and clear code, choose languages and platforms which are easy to recruit for, and develop system architectures which isolate components which require quick adaptability and those which require stability and testing, from each other, to mention only a couple of the steps you can take.

What to do to turn myself into a master?

Chris asks: "I would say I'm at the Journeyman level, working on getting to master, but I have no masters around me. Any advice on what to do to turn myself into a master?"

There are four important things you've got to gain an understanding in:

• people
• businesses
• yourself
• technology

Understanding people is the most important part. Learn to see how and what people see, when listening to them talk. Understand group dynamics. Pride, shame, guilt, fear, honor, fairness, and the bond of honesty. Understand how people see themselves and others. Not so as to deal with people dishonestly, but to be able to represent yourself to them in the light of shared understanding.

Understanding businesses is your second most effective leverage for results. Understand your customer, and their customer. Understand your customer's arrangement with their customers. How their organization is structured, and how their deals are structured. Learning "why" things are that way might not make you sleep better at night, but it might further your understanding of people. Understand the conceptual framework of business deals, and their terminology. Understand how and why business cases are developed. Learn how to explain people how you'll make them not only more money, but better money.

Understanding yourself frees you from some limitations you might otherwise have laboured under, and might help achieve contentment, even happiness, if one is so inclined. You can play a better game if you have the balls to see what cards you've been dealt. This is the best investment you can make, but there is no magic.

Finally, understanding technology. An excellent understanding of technology lets you amplify your other skills, but can be easily negated by slacking in other areas.

• Understand how microprosessors work, and how they came to be. Learn what the next year's processors will be like, and why the businesses developing them went that way. Understand how the CPU talks to the memory, and the timescales involved.
• Understand the broad concepts of assembler programming, if not the entirety of the actual practise. Understand how the SoC concepts differ from servers and desktops.
• Understand how rotational disks and SSDs work, and why, as well as file systems, and how people see them.
• Look at HP's and Dell's price lists for enterprise hardware, and learn what those things are and what do they do. Look at the prices, and compare the prices of acquisition to the costs of operating hardware.
• Learn what a good system administrator makes, and why.
• Understand what operating systems do, how they usually behave, what happens in anomalous situations, and what sysadmins do to avoid such situations.
• Learn how operating systems interact with the applications running on top of them, and how to make sure your application behaves well towards the operating system.
• Learn the most important thing about programming: how to communicate effectively with your colleagues and maintainers through code.
• Learn the second most important thing about programming: how to design efficient architectures which communicate their intent well.
• It's also good to learn how to write efficient code, although an efficient architecture should ensure that a moderate understanding of these principles is enough to keep each part relatively efficient.
• Learn how small a part of programming the actual programming language is, and how the entire ecosystem of integrations affects the end result of programming much more.
• Learn your tools. Learn when it's good business to pay for tools, and when not.
• Learn the basic history of interactions every major player in the software development landscape have left behind - you really shouldn't trust companies which screw their customers and partners time and again. You're not exempt, and it's better to learn that before than after.
• Keep abreast of the latest in libraries. Pick good ones, and teach your people to use them well.

I'm sure I've missed plenty of stuff, but this should get you started. It's Sunday, so it's a perfect time to pick one thing, and get a-chopping.

Lomaopinnot: JSF 2.0 + PrimeFaces 3.0

(Kopio eri taustaisille kollegoille lähetetystä sähköpostista.)

Hei, katselin loman aikana erilaisia teknologioita, joista yksi oli JSF 2.0 + PrimeFaces 3.0 RC2.

Java Server Faces on selainteknologiastandardi, joka tuo yhteen web-käyttöliittymäsuunnittelijat, backend-kehittäjät sekä kolmannen osapuolen komponenttikirjastojen toimittajat. Se standardoi eri toimijoiden väliset rajapinnat, sekä web-sovelluksen teknisten toimijoiden osuudet sovelluksien käytön elinkaaren aikana. Siitä on useita implementaatioita.

PrimeFaces on komponenttikirjasto, joka sisältää kaiken mitä B2B web-sovellukset yleensä tarvitsevat, helppokäyttöiseksi paketoituna.

Nämä teknologiat kilpailevat perinteisen HTML/JavaScript käsin kehityksen kanssa, sekä sovelluskehittimistä MS:n webbikehittimen, sekä esimerkiksi Google Web Toolkitin, Vaatimen, ExtJS:n, SmartClientin, SmartGWT:n ja ExtGWT:n kanssa. (Uutena mutta varteenotettavana kilpailijana kentällä on 2012 dust.js:n tyyppiset teknologiat, joita mm. LinkedIn on siirtymässä käyttämään, REST JSON-palveluiden kanssa.)

JSF-sovellukset koostuvat näkymätemplateista (Facelets) joissa HTML-koodin seassa määritellyt näkymäkomponenttien instanssit osoittavat sovelluksen taustaosioon, eli beaneihin (tiettyä sopimusta noudattava Java-luokka) jotka on annotoitu JSF:n kontekstitiedolla. Tyypillisessä sovelluksessa on joitakin taustaluokkia joiden elikaari kuuluu sessiokontekstiin, joitakin taustaluokkia jotka elävät spesifisessä keskustelukontekstissa (esim. jos sovelluksessa on osioita joiden halutaan toimivan samaan aikaan saman selaimen eri tabeissa) tai jopa yhden requestin eli HTTP-pyynnön pituisessa kontekstissa.

(JSF 2.0:n sisäänrakennettu keskustelukonteksti toimii hyvin epäintuitiivisesti, ja sitä varten Apache MyFaces CODI projekti on luonut standardia noudattavan custom scopen, joka toimii fiksummin. CODI:n käyttöönotto vaatii vain sen, että otat sen kirjastot mukaan projektiin, ja merkkaat taustapavun sen keskustelukonteksti-annotaatiolla.)

Hyvä esimerkki JSF 2.0 toimintaperiaatteesta löytyy PrimeFaces ajax multiupload demosta, http://www.primefaces.org/showcase-labs/ui/fileUploadMultiple.jsf

<h:form enctype="multipart/form-data">  
    <p:fileUpload fileUploadListener="#{fileUploadController.handleFileUpload}"
            mode="advanced" update="messages" multiple="true" sizeLimit="100000"
            allowTypes="/(\.|\/)(gif|jpe?g|png)$/"/>  
    <p:growl id="messages" showDetail="true"/>  
</h:form> 

Taustapapu:
 
public class FileUploadController {  
    public void handleFileUpload(FileUploadEvent event) {
        FacesMessage msg = new FacesMessage("Succesful", event.getFile().getFileName() + " is uploaded.");
        FacesContext.getCurrentInstance().addMessage(null, msg);
    }
}

Tässä esimerkissä ajax-komponentti uploadaa tiedostot, ja sen jälkeen päivittää dynaamisesti "messages" komponentin, jonka tehtävä on näyttää pienessä viestilaatikossa eventtinotifikaatioita. Jos metodissa tiedostot laitettaisiinkin talteen keskusteluskooppiseen papuun, johon vaikkapa esikatselukomponentti puolestaan osoittaisi, senkin voisi laittaa automaattisesti päivittymään, ja kokonaisuus toimisi edelleen odotetulla tavalla, vaikka komponenttien ja taustadatan vuorovaikutus ei ole mitenkään yksinkertaista.

Tässä mallissa kontrolli säilyy palvelinpäässä, kun taas kilpailevassa GWT-mallissa sovellus pyörii itsenäisesti selaimessa, ja tekee vain spesifisiä pyyntöjä taustapalveluihin. Siinä missä käsin koodattavissa järjestelmissä rajapinnat rakennetaan joko REST JSON tai XML päälle, tai enterprise architectien toiveesta SOAP:illa, JSF komponenttikirjastojen rakentajat voivat määrittää käyttäjälle näkymättömästi komponenttien toimintatavat, kunhan ne noudattavat JSF-standardin rajauksia.

Olin viimeksi kokeillut JSF:aa 1.0-versiossa, jossa se oli varsin kankea eikä vastannut tarkoitustaan, mutta nykyinen 2.0-versio vakuutti. Sillä voi rakentaa B2B sovelluksia valmiista komponenteista merkittävästi vaivattomammin kuin käsin HTML:aa ja JS:aa jyystämällä. Hintana on tosiaan se, että täysin uusia komponentteja on vaikeampi rakentaa, mutta 99%:ssa projekteista valmiissa komponenteissa pitäytyminen on vain positiivinen juttu projektin liiketoimintatavoitteissa onnistumisen kannalta. Jälleen uuden sliderikomponentin keksiminen ei oikeasti hyödytä ketään, mutta saman ajan käyttäminen tuotteen iteroimiseen asiakkaiden kanssa taas hyödyttää.

Lomaopinnot: Google Dart ohjelmointikieli

(Kopio eri taustaisille kollegoille lähetetystä sähköpostista.)

Hei, katselin loman aikana moniaita teknologioita, joista yksi oli Google Dart ohjelmointikieli.

Googlen strategia webbityökalujen suhteen on investoida siihen, että webissä pystytään tekemään mahdollisimman hyviä ja monipuolisia sovelluksia, koska he näkevät mainosbisneksensä markkinaosuuden, -position ja kannattavuuden olevan tämän globaalin capabilityn funktio.

Heillä on useita työkaluja tällä alalla, joista tunnetuin on Google Chrome verkkoselain, ja heille on kertynyt infrastruktuurikokemusta myös webin tämän hetken laajimman sovellusten toimitustavan, JavaScriptin osalta, V8 virtuaalikoneen ja Google Web Toolkit käännösympäristön mukana.

Googlen positio webin perusteknologioiden suhteen on 2012 se, ettei JavaScript itsessään vastaa riittävän hyvin huutoon, eikä sitä pysty inkrementaalisesti parantamaan riittävällä tavalla. Google Dart on heidän vastauksensa tähän ongelmaan. Se on mennyt konseptina hyvin läpi selainmarkkinoilla, ainoa vastustaja on Microsoft, jonka markkinaosuus on pudonnut jo alle 50%:n, ja jonka selainstrategian motivaationa on ollut heidän käyttöjärjestelmäbisneksensä, jonka nykymallista he ovat nyt aktiivisesti pyrkimässä ulos.

Dart vastaa kahteen ongelmaan: JavaScript ei ad-hoc kielenä tue edes keskisuurten projektien vaatimaa kehittäjien välistä viestintää, eikä sen ajamista ole sen ad-hoc ominaisuuksien vuoksi mahdollista optimoida tiettyä pistettä pitemmälle.

Dart-kieliset ohjelmat käännetään tällä hetkellä legacya varten mahdollisimman optimoitavaksi JavaScript-subsetiksi, sekä potentiaalisesti selaimiin kuten Chrome ja Firefox voi jatkossa tulla dedikoidut Dart-virtuaalikoneet.

Kieli tukee eri ominaisuuksin primääristi kahta eri käyttötapausta: normaaleja web-sovelluksia, sekä kirjastoja tai laajoja sovelluksia.

Pienet sovellukset kirjoitetaan hyvin pitkälle samaan tyyliin kuin tällä hetkellä JavaScript-sovellukset. Tyypitys on vapaaehtoista, ja skoopitus ja paketointi on huomattavasti intuitiivisempaa kuin JS:sa. Kielen peruskirjasto sisältää paljon juttuja, joiden puuttumista JS-väki usein kiroaa.

Kirjastot ja laajat sovellukset on tarkoitettu kirjoitettavaksi tyypitystiedon kanssa. Tällöin esim. muuttujat deklaroidaan tyyppitiedon kanssa, eli se mikä pienessä sovelluksessa kirjoitettaisiin val foo = "bar"; sanotaankin String foo = "bar";. Tällöin IDE osaa varoittaa, jos sovelluksesta yritetään käyttää kirjastoa väärin, ja työkalut osaavat mm. näyttää dokumentaation ja vaihtoehdot kuten C# ja Java-IDE:t tällä hetkellä.

Tyyppitieto on kuitenkin vain koristeinformaatiota, eli vaikka sanot Integer foo = "bar";, sovellus toimii edelleen odotetulla tavalla, vaikka IDE ja kääntäjä antavat varoituksia.

Mielenkiintoisia konsepteja, joilla on potentiaali tuoda merkittävästi enemmän ennustettavuutta selainsovelluksiin, jotka ovat toistaiseksi paras tapa toimittaa tuotteita mahdollisimman laajalle yleisölle.

Kannattaa tutustua. http://www.dartlang.org/ voi ladata Eclipse-pohjaisen IDE:n, joka sisältää kaiken tarvittavan.

IntelliJ IDEA 11 rocks!

IntelliJ IDEA 11 came out yesterday, and I've been evaluating it by adding some unit tests to a hobby project.

The user interface (on Linux) has improved tremendously from the previous major version. It's now better more eye-friendly than either Eclipse or NetBeans, for a user who'll be staring at it for hours on end.

Its Git integration is leaps and bounds past what either Eclipse offers, and you can't even mention NetBeans (7.1 RC1) Git "support" in the same sentence. It prompts you to "git add" files as you add them to the project, and has only very relevant stuff in the commit and push workflows. Its quick diff is far superior to Eclipse's, as is its review functionality. Finally, neither of its competitors offers anything close to what its git push interface does.

When writing unit tests, IDEA makes the smartest assumptions of contextual test running. Control-Shift-F10 not only works by default on Linux, unlike NetBeans' and Eclipse's defaults, it detects your context from your cursor position, running only your current test if your cursor is in a method, or the entire class, if the cursor is between methods. Eclipse can do the same, but it also has to pop up a dialog asking whether I want to run the unit test on a server (?), and its keybindings need a lot of tweaking to work on Linux. NetBeans just leaves the entire job of determining context to the user.

Where NetBeans and Eclipse still win, however, is suggesting different class constructors, by their parameters and JavaDoc.

NetBeans 7.1:

IntelliJ IDEA 11:

Testing Spring Data JPA

What I like about Spring libraries is that they just work, and they don't suddenly stop working. The APIs are usually well thought-out.

Spring Data JPA continues on the same track.

I've been going through recent developments in ORM / data access technology, and porting my tiny skeleton application to each. Today it's Spring Data JPA's turn.

You provide an interface like this:

And configuration like that:

After which Spring automatically builds, generates and injects a concrete implementation of that interface to your application, where you can use it like so:

Calling the findByNameLike method results in this SQL query being run:

Compared to many other ways of building simple database access I've tried and used, Spring Data JPA takes the cake.

The only complaint I have with it is that when integrating JPA entities with Scaml, you have to refer to their property getters like so example.getName instead of Scaml autodetecting bean properties by simply example.name, but that's more of an issue with Scaml than Spring.

Tools that make a difference

When I first started out in the software product development business, new and shiny tools frequently captivated my imagination.

Over the years, I've come to see that very few new tools truly let you do new things, or offer improvements more significant than the costs of their adoption.

First, let's go over two disappointments:

Ruby on Rails is marketed as a way to reduce time to market. It delivers, when your product is trivial microsites. Otherwise, the investment it requires, and the restrictions it imposes, more than offset its merits.

Likewise with Scala. It's sold as an improvement in language expressivity, but confuses "more" with "better". It's not better for the vast majority of business missions to be able and encouraged to perform the same primitive operations in six different, largely unlegible ways. It's perfectly OK if your mission is to produce academic papers, or sell a maximum amount of consultancy hours, but for a customer of product development, a loss both in the short and long terms. And that's even without going in the whole matter of upwards compatibility.

From the bitter comes the sweet, however, and a few tools which truly make difference have come out of the innovation around these things:

HAML is the best way to describe XML/HTML templates I've yet to come across. It introduces conceptual and communicative symmetry without taking away anything important. On the JVM side, Scaml is an implementation of the same ideas.

GitHub (and Git) changed small software project management. Its predecessors (SourceForge, other forges, java.net, Kenai et al.) were stuck in a rut with the concept of how people can fix bugs and customize existing software projects, and get those changes included in the upstream. The concept of person/team specific repository namespaces, pull requests, and the fork and merge big red buttons have let me do things that I'd otherwise not done, as well as easily include others' work.

JRebel has helped me to rapidly deal with a project in which I had to make changes to an extremely slow-starting undocumented buggy component, that hadn't originally been built to be testable. Most of the time, JRebel just works, especially with a Spring stack. When I've had problems with it with less-reliable just-released JEE6 stack components, Anton has responded to support mails in hours.

Testing ORMLite

While various JPA implementations are the standard for good reasons, I took the time to shop around for some of the lighter ORM tools, especially one with a reasonable SQL query builder DSL.

ORMLite won this round, and I integrated it into my skeleton application, where it replaced Spring JDBC.

The @DatabaseTable and @DatabaseField annotations come with far fewer rules than JPA beans. The _ID and _NAME constants are used with the query builder.



Unfortunately Spring doesn't automagically translate the SQLException to DataAccessException, so I have to use the translator manually.



Configuring ORMLite with Spring is painless. Had to switch HSQLdb to H2, since HSQLdb threw some permission exceptions when used with ORMLite.

Exciting stuff of November 2011

http://www.infoq.com/presentations/The-Kotlin-Programming-Language

http://www.dartlang.org/

http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

http://ormlite.com/

http://cloudfoundry.org/ https://github.com/cloudfoundry

Spring 3.1 MVC skeleton project upgrade

Over the weekend I upgraded my Spring project skeleton to include Spring 3.1 MVC support.

The skeleton app uses Scaml, a HAML-variant, as its view layer. The index page merely lists all the examples we have available.

It also contains the standard dependencies I usually recommend: Spring Framework 3.1, Joda-Time 2.0, Guava 10, LogBack/SLF4j, JUnit, Mockito and PostgreSQL.

The skeleton application is available as a Maven project at my BitBucket page at http://dev.gueck.com/project-skeletons/src/tip/spring3-web. It can be executed with the command mvn -Dspring.profiles.active=dev jetty:run.

The embedded development database gets re-initialized with a schema and test data at every application restart.

The Spring MVC controller, service and DAO classes don't need much introduction.

The service makes the business decisions, such as whom to exclude, and also demonstrates Guava's usefulness in collection handling.

The easiest way to do a simple CRUD DAO is with Spring JDBC, but it gets progressively more complex as your domain tables/classes get more complex, and pretty soon you're better off with just going with JPA.

The skeleton domain class uses Guava's ToStringHelper, and contains a static instance of Spring JDBC's RowMapper.

I like to situate some or many of the Spring JDBC helpers in the actual domain class, but the location varies depending on the various architectural visions you might embrace.

The Spring XML configuration file now demonstrates the new mvc:resources-tag, as well as profiles, and how to create a embedded development database with them.

Email MIME container handling inside PostgreSQL with PL/Python

Some examples from a discussion with some colleagues of how to best handle complex LOB parsing for rare ad-hoc analytical business database queries.

Google Dart + JetBrains Kotlin = ethical hotness

I've written software for pay in many various languages, and lately mostly in Java, since professional ethics require me to recommend and use the language with the most balanced match of individual, group and business features to my employer's business objectives and mission.

What excites me about a couple new tools coming out in the 4Q2011-1H2012 timeframe, is that they seem credible competitors for tool choices compatible with professional ethics.

Google Dart came out today, and offers the promise of a strong player bringing significant change to the best way of delivering applications to both consumers and business users today.

JetBrains Kotlin is yet to be published, but is proposed by one of the strongest niche players in the software tools landscape, and offers to actually reduce complexity of backend programming, without sacrificing the supporting tooling which gives participants to the Java ecosystem a lot of good value. It's different enough from Java to be worth an investment, but evades the trap many of its purported competitors fell into - optimizing the language for academic papers, and pushing out duplicate half-baked features after another.

X79 Siler + i7-3930K: Java-sovellusten palvelinraudan sweet spot 4Q2011-1Q2012

Tyypilliset Java-palvelinsovellukset, business-tietokannat ja business-virtuaalikoneet eivät käytä CPU:ta tapissa, vaan niiden kustannustehokkuuden portinvartijana on keskusmuisti, ja muutaman kymmenen gigan datasettiin kohdistuvat IOPS:it.

X79 Siler-emolevyt tarjoavat mahdollisuuden kahdeksaan DDR3 slottiin per prosessori, eli 64 GB (latenssiltaan symmetriseen, NUMA:n tarpeettomuuden vuoksi) keskusmuistiin, yhdistettynä LGA2011 kantaiseen prosessoriin, kuten Sandy Bridge-E i7-3930K.

Intelin 320-sarjan SSD-levyt eivät (PostgreSQL-kehittäjien kokeiden mukaan) tarvitse superkapasitaattoria virtakatkoista selvitäkseen, ja niiden hinnat liikkuvat parissa eurossa per gigatavu, melko tyylikkäillä IOPS-luvuilla.

Tälläinen prosumer-vallankumous tarjoaa uskaltavalle ja yrittävälle firmalle mahdollisuuden rakentaa Suomen (ja lähialueiden, jos vähän näkee vaivaa) mittakaavaisiin tuotteisiin hyvin edullisesti ominaisuuksia, joiden kustannukset olisivat olleet satakertaisia vielä vuosi tai pari sitten.

Jotta voi ottaa ilon irti rautapuolen kehityksestä, pitää vaan pysytellä kauempana harrastajaporukan ohjelmistokehityksen työkaluista, kuten skriptikielistä jotka eivät vaan käytännössä pysty käyttämään samanaikaisesti kahtatoista säiekontekstia, ja käyttämään keskusmuistia säieturvallisesti datasetin käsittelyyn.

8GB registered DDR3 hinnat saisivat vielä pudota...

Charliella on asiaa

Etenkin relevantti Norjan tapahtumien jälkeen...