Athegas Peter Hellberg (@peterhellberg) och Andrew Crookston (@acrookston) har precis spenderat några dagar i Boulder, Colorado, USA (karta) för att medverka på konferensen Mountain.rb – ”A ruby pioneers conference” .

Konferensen lockade med flera ledande personligheter inom Ruby communityn som Jim Weirich (@jimweirich) uppfinnare av Rake, Blake Mizerany (@bmizerany) uppfinnare av Sinatra och Evan Phoenix (@evanphx) lead developer på Rubinius ett alternativt Ruby VM, samt många andra duktiga talare.

Första dagen spenderade vi med en promenad i staden där vi bland annat hälsade på hos Dojo4 – en lokal utvecklingsbyrå, och tog oss upp till en av Boulders mer kända utsiktsplatser, Chautauqua som ligger vid foten av Flat Irons (bilden). Boulder ligger fantastiskt vackert vid 1,655 meter höjd precis där Rocky Mountains möter The Great Plains. Längs med hela den västra horizonten, från norr till syd, tornar bergen rakt upp ur marken som en vägg. Vänder man blicken mot öster ser man bara platt mark så långt ögat når.

Boulder har drygt 100 000 invånare och Colorados officiella (och största) universitet med ca 30 000 studenter – en stad som kanske närmast kan liknas vid Uppsala hemma i Sverige. Trots den lilla storleken har Boulder en stor och aktiv teknik scen med flest systemutvecklare per capita och över 100 s.k. startups. Jämfört med te.x. San Francisco har man en väldigt öppen kultur där man gärna delar med sig av erfarenheter och hjälper aktivt varandra. Regelbundna möten arrangeras där alla får komma.

Eftermiddagen bjöd på registrering med mingel. Arrangören Marty Haught (@mghaught) hade till konferensen hittat på en liten kort-bytar lek där man vid registreringen fick välja mellan fyra karaktärer; Cowboy, Prospector, Homesteader och Trapper. Detta val visade sig ha lite konsekvenser senare under konferensen när vi fick spelreglerna förklarade för oss tillsammans med en uppmaning att skapa valfritt program för att räkna poäng eller göra annat kul med korten vi hade.

Vi träffade bland andra Brennan Dunn (@brennandunn) som bygger ett riktigt intressant öppet källkods-projekt som heter Rack::CMS, ett lättviktigt CMS som gör det möjligt för icke tekniker att ändra textinnehåll på en hemsida, använder Redis som lagringsmotor. Peter Williams (@pezra) med Resourceful, ett gem för cachning av HTTP requests och Ryan Angilly (@angilly) lokal entreprenör som bland annat byggt gwop.us ett mikrobetalningssystem för bloggare.

Läs mer om konferensen i följande blogg poster

Mountain.rb – Dag 2

Mountain.rb – Dag 3

Responstid före och efter jag bytt ut ancerstorview-taggen

Vad är ancestorView?

ancestorView används för att skapa en hierarkisk vy av sektioner utgående från den sektion du anger. Inget speciellt avancerat eller konstigt. Det borde inte heller vara jobbigt för systemet att skapa vyn, tyvärr sker något under ytan som ställer till det. Berätta gärna vad i kommentarerna.

Hur det kan se ut (före)

Ett vanligt sätt att använda sig av ancestorView är för att exempelvis bygga en sökväg till en navigering:

<section:ancestorView id="sectionView" section="${article.homeSection}" includeRoot="true"/>
<menu:use id="navigation" treeName="myMenuName">
	<c:set var="count" value="1"/>
	<view:iterate id="item" name="sectionView">
		<menu:item id="current" sectionId="${item.id}"/>
		<c:choose>
			<c:when test="${count eq 1}">
				<c:set var="sectionPath" value="${current.text}"/>
			</c:when>
			<c:otherwise>
				<c:set var="sectionPath" value="${sectionPath}/${current.text}"/>
			</c:otherwise>
		</c:choose>
		<c:set var="count" value="${count+1}"/>
	</view:iterate>
</menu:use>

Skapa en lättviktig ersättning till ancestorView

En enkel väg till ett liv utan ancestorView-taggar är att skapa en mycket enkel custom tag. Nedanstående implementation har inte stöd för precis allt du kan göra med Escenics variant, men den gör jobbet för de flesta användningsfallen. Jag döpte den till ancestors.tag och la den i /WEB-INF/lib/tags/section.

<%@tag body-content="empty"%>
<%@tag import="neo.xredsys.api.Section, java.util.ArrayList"%>
<%@attribute name="id" required="true" rtexprvalue="false"%>
<%@attribute name="section" type="neo.xredsys.api.Section" required="true"%>
<%@attribute name="includeRoot" type="java.lang.String" required="false"%>
<%@variable name-from-attribute="id" alias="sectionPath" scope="AT_END"%>
<%
	final ArrayList sections = new ArrayList();
	if (section != null) {
		do {
			sections.add(0, section);
			section = section.getParent();
		} while (section != null && ("true".equals(includeRoot) || section.getParent() != null));
	}
	jspContext.setAttribute("sectionPath", sections);
%>

Det enda som egentligen sker här är att jag bygger upp en lista med föräldrasektioner i omvänd ordning genom att anropa Escenics API. Detta går av någon anledning massor med gånger snabbare.

Hur det kan se ut utan ancestorView

<%@ taglib prefix="sec" tagdir="/WEB-INF/tags/section" %>
<sec:ancestors id="sectionView" section="${article.homeSection}"/>
<menu:use id="navigation" treeName="myMenuName">
	<c:forEach var="item" items="${sectionView}" varStatus="itemStat">
		<menu:item id="current" sectionId="${item.id}"/>
		<c:choose>
			<c:when test="${itemStat.first}">
				<c:set var="sectionPath" value="${current.text}"/>
			</c:when>
			<c:otherwise>
				<c:set var="sectionPath" value="${sectionPath}/${current.text}"/>
			</c:otherwise>
		</c:choose>
	</c:forEach>
</menu:use>

Eftersom jag inte längre arbetar med en vy av sektioner, kan jag iterera över listan med föräldrasektioner med en vanlig c:foreach med fördelar som varStatus, mm.

Slutsats

Om du använder Escenic i någon 4.x-version och om du får några träffar när du söker på ancestorView i din kodbas, finns all anledning att se över ett byte!