Tillsammans med Göteborgs utvecklarcommunity  arrangerar Squeed för andra året mobilutvecklingskonferensen dev:mobile. Årets konferens bjuder på inte mindre än 12 presentationer samt keynoten “Panel reflection about the future of mobile platforms from a developers perspective”.

Flera kända företag kommer och håller presentation som bla Spotify, Microsoft, IBM, Opera mfl.

Och det bästa av allt med en konferens som arrangerar av användargrupperna i Göteborg är att det är helt kostnadsfritt att delta! Anmäla och mer information finns här.

Är du en systemutvecklare?

Kanske någon finner ett fel i koden

För mer information om Squeed, besök vår hemsida Squeed.com

Squeed bjuder in till Google I/O Extended i Göteborg

Om du inte har möjlighet att åka till San Francisco för Google I/O så är det här chansen för dig att vara med på distans. Vi kommer att äta lite mat och titta på keynoteen från Google I/O. Vi håller till i Squeeds lokaler på Södra Larmgatan 4 Karta

Agenda

17:00-18:00 Öl och pizza och mingel
18:00-20:30 Google I/O Keynote (streamad från USA)

Anmälan via Javaforum

Har du länge drömt mardrömmar om din kod? Eller kanske du är en av dem som önskar att Code Review var en del av er arbetsprocess? Kanske du redan har sådan process? Mattias Jiderhamn från B2B företaget Expert Systems i Alingsås kommer och gästar nforum den 23 april och delar med sig av sina idéer och tankar kring just detta ämne.

Personligen är jag förvånad över att det är så få företag som lägger energi på att införa alla dessa mjuka ting i sina arbetsprocesser. TDD, Code Review, Acceptans Review m.m. Oftast brukar det bero på att de som bestämmer inte själva vart kodare och eller så finns det brister i förståelse för vad en bra process faktiskt innebär.

Jag kan förstå denna sits samtidigt som jag är stor motståndare här. I min värld har jag alltid strävat efter att det inte finns något som heter övertid, det finns inget som heter buggar m.m. Vi vet alla att det visst finns det men om du envist inte vill tillåta dem för dig själv och samtidigt även vill kunna utföra ett bra jobb kommer du automatiskt som programmerare hela tiden tvinga dig själv att hitta de effektiva och smarta vägarna att gå för att just slippa sitta över, slippa buggar m.m. Du nyttjar TDD, du tänker en extra gång innan du hackar din kod. Du bollar idéer med dina kollegor, du ber någon kollega i smyg kolla på din kod m.m. Vi brukar oftast bli kallade de Pragmatiska utvecklarna. Tycker dock det är synd att det inte direkt ligger lika mycket fokus på de Pragmatiska säljarna, de pragmatiska kunderna mot utvecklarna.
Många processer försöker men allt för många förstår inte processerna i sig. De tror oftast det bara är för utvecklarna skall hinna göra med features och missar att de själva egentligen också ingår i processen.
Känslan på en bra konferens brukar i många fall vara ”Det är fel folk som sitter här, vi kan detta, synd våra chefer inte är här och lyssnar på detta, det är de som behöver denna kunskap inte vi…” Du känner igen dig va? Tänkte väl det.

Jag fick höra en skrämmande historia en gång.
Köparen: Vad är detta? Test 40timmar? Code Review 10h? Det har jag aldrig betalt för förut, stryk det.
Säljaren: Ok.

Ta ansvar, stå på dig, kan du inte övertala din överman, gör bevis på att dina idéer faktiskt ger värde.
För så länge du kan leverera lufttid och inte siffror är du oftast rätt rökt. Dvs. kan du inte bevisa att det ger effektivitet kommer du heller inte få till det, då extra arbete (som de ser det) ökar bara deras siffra med den tid som redan finns, de ser sällan att tillägg drar av tid.

Andra ämnen vi tar upp på nforum den 23 April är TypeScript med John Tjust från oss på Squeed.
Även Filip Ekberg gästar oss med att prata om Async i C#.

Vi ses, anmäl dig på nforums egna sida.
www.nforum.se

Mvh Johan

Fredrik Normén på Squeed kommer den 30:e April att prata om Continuous Delivery och hans erfarenheter kring området i det projekt han sitter i just nu för ett finansbolag. Ni kommer att få grundläggande förståelse kring begreppet Continuous Delivery, samt hur Fredrik och hans team har valt att lösa vissa problem i sitt utvecklingsteam, allt från process, källkodshantering, branchning, automatisering etc,  detta med hjälp av Microsoft Team Foundation Server 2012 och NuGet samt andra verktyg och hack!

Detta är ett event via Swenug som sponsras av Squeed AB.

Anmäl er här:

http://www.swenug.se/events/gbg-continuous-delivery

Lördagen den 27:e Apirl kommer Global Windows Azure Bootcamp att genomföras runt om i världen, över 90 st platser. Vi på Squeed tillsammans med SweNug har valt att sponsra och vara med och arrangera denna bootcamp i Göteborg. Det blir en dag med labbar, så ni som är nyfikna på Windows Azure så är detta är ett bra tillfälle att få möjlighet att testa på och labba med Microsoft cloud services.

Vi börjar kl 10:00 och håller på fram till kl 15:00.

Det finns dock bara 20 platser, så försten till kvarn.

http://www.swenug.se/events/global-windows-azure-bootcamp

Squeed bjuder in till en ny omgång av kursen i testdriven utveckling (TDD). Denna omgång av kursen vänder sig till dig som är Java-utvecklare och nybörjare inom TDD-området. Kursen omfattar fem tillfällen om ca två timmar där du kommer få praktisk erfarenhet av att utveckla kod testdrivet.

Upplägget med datum (spikat) och ämnen (lite mer rörligt) ser ut så här:

tors 25 april, kl 16-18: TDD, basics
mån 13 maj, kl 16-18: TDD, test backlog och “enough upfront design”
tors 23 maj, kl 16-18: TDD + OO, classical approach
ons 5 juni, kl 16-18: TDD + OO with mock framework
tors 20 juni, kl 16-18: [något av: Clean Code, Mockist approach, BDD, three-clause style, Refactoring]

Kursen, som är gratis och har plats för 10 deltagare kommer hållas på svenska och leds av Fredrik Wendt, Niclas Åstrand och Peter Kristoffersson. Vi ger förtur för nya deltagare och du kan anmäla ditt intresse genom att fylla i ett enkelt formulär för intressanmälan.

Den stora (Java-)konferensen Devoxx har ynglat av sig till Frankrike tidigare och i år har även UK/London (och Belgien) fått sig en lokal avstickare. Jag deltog tyvärr bara på en mindre del av konferensen, och fick i sista stund reda på att jag var tvungen att ändra slides till “det obligatoriska formatet” (som det visade sig att ingen förutom Oracle-anställda egentligen brydde sig om) så jag blev inte så mycket deltagare som jag hoppats. Hur som helst – jag pratade om Business Environment Coding Dojos, dvs delgav en del erfarenheter om vad jag sett fungerat och inte fungerat, samt vad jag tror är nyckelfaktorer till att företagsinterna dojos är framgångsrika. Med framgångsrik menar jag att de uppnått ett mål som ger affärsvärde – allt som oftast har det varit att få till en beteendeförändring, t ex större testfokus, “bry sig om hur bygget går” eller lyckas tillämpa nya kunskaper i dagliga arbetet. Om de nya “färdigheterna” inte används i det dagliga arbetet ser jag det alltså som en mindre lyckad investering.

Devoxx UK 2013 (med slogan “Mind the Geek”) uppskattade jag hade någonstans mellan 400-500 besökare, två “vanliga” dagar med föredrag med parallella hands-on labs “en trappa upp”. Lokalerna var kanon (allt hängde ihop smidigt och labdelen var inte “remote” på något sätt utan ett naturligt ställe att gå till), tekniken kanon (nej, det fanns ingen VGA-sladd så långt ögat nådde), mingelarean lagom stor och perfekt uppblandad med uställare som “omringade” ett öppet golv. Maten var kanske något sämre än väntat (smörgåsar – japp, England i ett nötskal?) men som tur var fanns trevligt folk som kompenserade det hela.

Av det jag lyssnade på tyckte jag Attilla Szegedi om Nashorn var mest intressant för mig: en “native”-implementation av ECMAScript som skeppas med JVM:en. Det fanns några mindre delar kvar att önska (prestanda inte minst), men en riktigt rolig grej var att de uppe på JVM-teamet i Stockholm har en “port” av Node.js där man bytt ut all C-kod mot att istället använda vanliga Java SE-paket. Klart intressant och de räknar med att kunna dela med sig av källkoden snart. (Grizzly för nonblocking IO.)
Bindningar av variabler mellan ECMAScript och Java-koden är ju intressant, men känns också som något man generellt sett skall undvika så mycket som möjligt.

Jag ser iaf fram emot att kunna labba med en variant av Node.js på min JVM. Prestandan är inte i närheten av V8 (och kommer antagligen aldrig kunna komma ikapp heller, det är inget mål), men just Nashorn är lite “äta sin egen hundmat” – första gången som de faktiskt använder invokedynamic – utöver för lambdas givetvis, men även det kommer ju först i version 8 som är planerad att släppas i höst.

Det var en hel del om just lambdas, hur man kan jobba bra och effektivt med dem, hur de fungerar, hur man ska tänka, hur standard API:er utökas (stream-ifieras). Mycket snack om fork-join-pooler och konfig av dem, men också JavaFX och givetvis fanns Raspberry Pi:s lite varstans.

Oavsett, Jeff Attwoods (Coding Horror-människan) regel verkar stämma och Oracle vill gärna att JVM:en hjälper till: “any application that can be written in JavaScript will eventually be written in JavaScript”.
(Btw, Jeff är ju en .Net-älskare men skrev nyligen öppet om varför/när han väljer bort det, och sticker ut hakan med “If you squint your eyes a little, I think you can see a future not too far in the distance where .NET is a specialized niche outside the mainstream”).

Sammanfattning: välorganiserat, snyggt skött, trevliga, välfungerande lokaler. Inte lika stort som JFokus. Få vågade sitta i Oracles beanbags.

X vs Y

Skrev nyss om agila affärer och länkade till Thoughtworks sida där de beskrev hur de lämnat det så organisatoriskt skadande sales commission-tänket. Av en händelse läste jag idag två X vs Y-inlägg hos Fog Creek (folket bakom Trello, Stackoverflow, “Joel on Software” etc) och det första var på just ämnet “Why do we pay sales commision“. De drar slutsatsen att det kommer från två olika synsätt på sina anställda:

Theory X which assumes that people are lazy, want to avoid work and need to be controlled, coerced, punished, and lavishly rewarded in order to perform.

Theory Y which assumes that people are self-motivated, derive satisfaction from their work, are creative, and thrive when given autonomy.

Gillar åsikten om konsekvensen av X:

Theory X demands a lot of managerial control and tends to demotivate, generate hostility, and generally make people into sour pusses.

Git vs Mercurial

På X vs Y-temat har Fog Creekarna klämt ur sig en ny version av Kiln, nu med Harmony där man helt enkelt lyckats – mer eller mindre – transparent få ett repo att agera så att man kan interagera med det från både git och mercurial utan att bry sig om vad det “egentligen” är på andra sidan. (hg bookmarks för git branches, och git refs för hg branches – ja, det finns antagligen fler problemområden de varit lite olika kreativ att kringgå.)

Java vs Java?

En helt annan reflektion – jag såg två helt olika annonser som skulle locka “Java-folk”. Det finns väldigt mycket som snurrar på JVM:en och detta ämne blir dagens avslutande X vs Y, eller är det möjligen bara en vanlig Feature Envy?

Java X: JSP, JSF, CDI (inte DCI), JEE, EJB, JPA, JAX-*, WS-*, Spring-*, …

Java Y: Scala, Clojure, JQuery, Event Sourcing, Concurrency, Distributed Computing/P2P, Scrum, Cloud, NoSql, REST, CQRS, DevOps, AWS, EC2, Android, HTML5, MongoDB, Functional programming, Mule, DCI, BigData/Hadoop, JRuby, Akka, Neo4j, Qi4j …

Fråga: Hur lång tid tar det att sätta upp Continuous Integration, om man har lite bråttom? (Jag var iväg på en utbildning och den virtuella maskinen som skulle användas för koddelning och CI var trasig på flera sätt.)

1. Starta virtuell maskin (Amazon i detta fall, valde en m1.large), Ubuntu Server 12.10. Lägg till portar 8080 och 9000 i den Security Group som används.
2. ssh -i pem ubutu@machine-at-amazon
3. sudo -s
4. aptitude install openjdk-7-jdk git
5. wget http://updates.jenkins-ci.org/latest/jenkins.war; java -jar jenkins.war &
6. wget http://dist.sonar.codehaus.org/sonar-3.4.1.zip; unzip *.zip; ./sonar-3.4.1/bin/linux-x86-64/sonar.sh start
7. http://machine-at-amazon:8080/pluginManager – installera “Jenkins GIT plugin”, “Jenkins Sonar plugin”
8. http://machine-at-amazon:8080/configure
   1. JVM: /usr/lib/jvm/java-7-openjdk-amd64
   2. Sonar Runner: Install from Codehaus
   3. Maven: Install from Apache
   4. Sonar: Add Sonar
9. Skapa repo på Github, peta in en pom.xml, kopiera URL (HTTP, read only) till repot.
10. http://machine-at-amazon:8080/view/All/newJob – ange ett namn, Maven 2/3-projekt. Peta in URLen till Github-repot, välj “Sonar” som Post-build step (längst längst ner)***
11. Tryck på Play-(bygg-)knappen – kontrollera att allt fungerar. Högerklicka på Play-knappen och kopiera länken
12. Under Settings på Github-repot, gå till Service Hooks, Webhook URLs och klistra in URL:en från Play-knappen på Jenkins
13. Peta på en fil i projektet lokalt (t ex stega nummer i pom.xml), git commit, git push. Kontrollera att Jenkins startar automatiskt (webhook från Github), att informationen trycks över till Sonar (http://machine-at-amazon:9000/).

Resultat

Komplett miljö igång på under 15 minuter. Användes i fyra dagar – kostnad: ~20 USD.

Ett par brasklappar

*** Gällande aktivering av Sonar som ett post-build step – detta gör ju att feedbackloopen blir långsammare för happy path: dvs om bygget går bra kommer analysen Sonar utför göra att det tar längre tid innan man får “grön flagg”. Om bygget däremot är trasigt är feedbackloopens längd oförändrad.

CloudBees är ju också ett givet alternativ och ännu roligare ihop med Sauce Labs om man t ex behöver Selenium WebDriver.

Både Jenkins och Sonar kan givetvis installeras som vanliga Ubuntu/Debian-paket istället, vilket är mer lämpligt för en permanent lösning (troligen vill man då fundera över databas och konfiguration till Sonar, kanske autentisering osv).