Haral's Blog
Sporadic rant on java, maven, enterprise application integration, patterns, testing, people, legacy, people and so forth. And some cooking.
torsdag 16. februar 2012
Curry tom kha (suppe)
Jeg har prøvd ganske mange ganger å gjenskape den utrolig smaksrike maten fra Thailand, stort sett uten hell. Heller ingen av restaurantene jeg har vært på her i landet klarer dette 100%. Denne suppe-oppskriften er det nærmeste jeg kommer, og sammenliknet med halvfabrikat thaimat er den en smaksbombe. Du er herved advart :)
2 kyllinger, gjerne grillet, renset og klippet i småbiter
1,5 liter kyllingkraft, typisk fra 2-3 skrog
2 løk, hakket
1 pk sjarlottløk, hakket
2 gulrot, revet
1 ss basil stir fry paste
2 ss red curry
2 ss green curry
8 stilker lemongrass, knust
8 fedd hvitløk, hele
1 boks straw mushrooms, delt
10 champignonger
2 knoller galangal
1 knoll ingefær
8 limeblader
1 ss koriander
1 ss tamarind paste
2 lime, saft og revet skall
5 ss fiskesaus
10 små tomater
4 ss brunt sukker
2 bokser kokosmelk 16%
masse fersk koriander
Fremgangsmåte:
- stek løk, gulrot, curry og basil paste
- hell over kraften
- tilsett nesten alt annet
- kokes i en liten time
- kylling, kokosmelk, fersk koriander tilsettes helt til slutt
onsdag 8. februar 2012
Erfaringer med trusselmodellering
Sammendrag av presentasjonen min på Software 2012 - Erfaringer med trusselmodellering.
Trusslemodellering er en plattform for kommunikasjon. Kunden lurer på hvordan problemer er løst, og leverandøren har behov for å forklare det samme, og i tillegg belyse antagelser og konsekvenser av endringer. En slik plattform er nyttig gjennom hele livssyklusen, og kanskje særlig som dokumentasjon av tidligere avgjørelser.
En veldig viktig egenskap ved en trusselmodell, er konsistens mellom opptegning av systemet, og analysen av det. Derfor er det nyttig å bruke et verktøy som besørger denne konsistensen, og synliggjør eventuelle avvik. Truslene kan modelleres med "STRIDE"-prinsippene: spoofing, tampering, repudiation, information disclosure, denial of service og elevation of privilege. Hvert av disse appliseres til de forskjellige delene av systemet, som er modellert med komponenter som dataflyt, prosesser, aktører og datalager.
Gjennom analysen kommer man frem til diverse tiltak som er gjort tidligere. Av og til finner man også mangler. Modellen beskriver hvor inndata kommer fra eksterne aktører. Generelt fins det flere aspekter som kan tas ut som forskjellige rapporter som passer ulike roller, feks arkitekt, funksjonelt ansvarlig, kundens sikkerhetsansvarlig, prosjektleder etc.
Ved å bruke en dedikert applikasjon til trusselmodellering er det også enklere å oppdatere og endre modellen. Mangler og endringer blir svært synlige i analyse-bildet, og lar seg enkelt oppdatere. Dermed er det også enkelt å "holde liv" i modellen.
Dessuten er denne prosessen en veldig nyttig kunnskapsdeling mellom kunde og leverandør. Kunden (eller driftsleverandøren) synliggjør situasjonen i produksjonsmiljøet. Leverandøren viser hvordan løsningen opprinnelig var planlagt. Prosessen fører til en dyptgående modell av den eksisterende situasjonen i produksjon.
Disse erfaringene er basert på bruk av Microsoft SDL Threat Modelling Tool.
Trusslemodellering er en plattform for kommunikasjon. Kunden lurer på hvordan problemer er løst, og leverandøren har behov for å forklare det samme, og i tillegg belyse antagelser og konsekvenser av endringer. En slik plattform er nyttig gjennom hele livssyklusen, og kanskje særlig som dokumentasjon av tidligere avgjørelser.
En veldig viktig egenskap ved en trusselmodell, er konsistens mellom opptegning av systemet, og analysen av det. Derfor er det nyttig å bruke et verktøy som besørger denne konsistensen, og synliggjør eventuelle avvik. Truslene kan modelleres med "STRIDE"-prinsippene: spoofing, tampering, repudiation, information disclosure, denial of service og elevation of privilege. Hvert av disse appliseres til de forskjellige delene av systemet, som er modellert med komponenter som dataflyt, prosesser, aktører og datalager.
Gjennom analysen kommer man frem til diverse tiltak som er gjort tidligere. Av og til finner man også mangler. Modellen beskriver hvor inndata kommer fra eksterne aktører. Generelt fins det flere aspekter som kan tas ut som forskjellige rapporter som passer ulike roller, feks arkitekt, funksjonelt ansvarlig, kundens sikkerhetsansvarlig, prosjektleder etc.
Ved å bruke en dedikert applikasjon til trusselmodellering er det også enklere å oppdatere og endre modellen. Mangler og endringer blir svært synlige i analyse-bildet, og lar seg enkelt oppdatere. Dermed er det også enkelt å "holde liv" i modellen.
Dessuten er denne prosessen en veldig nyttig kunnskapsdeling mellom kunde og leverandør. Kunden (eller driftsleverandøren) synliggjør situasjonen i produksjonsmiljøet. Leverandøren viser hvordan løsningen opprinnelig var planlagt. Prosessen fører til en dyptgående modell av den eksisterende situasjonen i produksjon.
Disse erfaringene er basert på bruk av Microsoft SDL Threat Modelling Tool.
tirsdag 8. november 2011
Building a telescope from your old optics
I've had a Tamron 500mm f/8 reflector lens around for years. Now I've finally put it to use. With fixed aperture f/8 it's rarely useful for photography, but using it as a secondary telescope is actually really clever (got the idea from someone on the net, obviously).
The mount goes, from left to right:
- reflector lens
- t2/fd adapter
- fd rear cap /w drilled hole & glue
- celestron t-ring/eyepiece holder
- 1,25" eyepiece
And there's a bonus: because of the customised fd lens cap, it is possible to mount the eyepiece to any of my old Canon FD lenses. Works great with 35-105 f/3.5 and 100-300mm f/5.6 for both 25mm and 12mm eyepieces. Way to re-use your FD optics :)
fredag 29. april 2011
Innbakte pølser på grillen
En enkel og knallgod fredagsrett:
- 1 pk pølser
- 1 klump fin deig
Lag en lang, flat stripe deig, og surr den rundt pølsa. Pensle med litt smør. Grill på lav varme i ~5 minutter. Enklere blir det ikke :)
fredag 8. april 2011
Firespice

Røykespon bruker man vanligvis til å røyke fisk og denslags, men Weber har en type litt større trebiter som funker bra i grillen. Firespice er små biter av treverk av feks mesquite, hickory eller epletre som kan puttes i grillen for å lage litt ekstra røyk.
Det funker flott til biff, og også pizza som jeg skrev om i forrige post. Det er lurt å legge flisene i vann et døgn i forveien, så de brenner mindre og ryker mer.
torsdag 7. april 2011
3xP: Predicting production performance pt. 2
In my previous post, I ranted on about testing environments, and how everything would look like if us tech nerds were to run a project. Well .. everything would be tested and running smoothly, but the users might not enjoy the command line interface.
Anyway, what to do when you're unable to reproduce performance issues that appear in production, disregarding excuses and previous assumptions ?
There are a number of non-intrusive metrics that is - or should be - available from your production environment. These should be used to monitor the application, and warn whenever something is about to come out of control.
But since we're already working on this - I guess the metrics failed, or someone did ignore the alerts and flags and whistles. Here's my short recipe for finding performance bottle necks:
1) Draw a diagram of the application stack
2) Map out the different diagnostics available from each layer
3) Figure out if each layer itself believes it is healthy
4) Let each layer figure if the layer below is healthy
5) Start fixing issues from the bottom. With each change, re-assert that the layers below still are hearty.
A typical example would be a long-running sql statement. It would be visible in database monitoring tools, and easily fixed either in the database or by altering the statement. Good.
But it's still a bottle neck. Why? Looking good at the data layer, there may still be issues with transporting the query results to the application server. So, next you look at the database driver, and see that there are a lot of result pagination. You query yielding 20 000 rows gets paginated into 1000 chucks of 20 rows.
So you fix the prefetch size, and now things run a bit smoother. But there's still some issues, because instantiating all of these results can take a while.
So you may be altering the data transfer model to be be more precise of which objects to fetch. But in doing so, you complicate the query again, yielding longer execution time ..
And so on you weave a path upwards to the application level, possibly introducing and resolving several issues as you go. This process is orders of magnitude simpler if you are able to simulate the results instead of actually deploying small fixes to production. In addition, you may unknowingly touch upon stuff that break other performance metrics. So again - monitoring of the entire stack is crucial.
Finally, when you reach a conclusion and have solved all of the current issues - ensure that your current footprint or benchmark is monitored for changes. Future maintenance and development will surely introduce new issues. Get at them early instead of letting them grow and interweave with each other. Then your next job won't be untying complicated knots of system behavior.
Anyway, what to do when you're unable to reproduce performance issues that appear in production, disregarding excuses and previous assumptions ?
There are a number of non-intrusive metrics that is - or should be - available from your production environment. These should be used to monitor the application, and warn whenever something is about to come out of control.
But since we're already working on this - I guess the metrics failed, or someone did ignore the alerts and flags and whistles. Here's my short recipe for finding performance bottle necks:
1) Draw a diagram of the application stack
2) Map out the different diagnostics available from each layer
3) Figure out if each layer itself believes it is healthy
4) Let each layer figure if the layer below is healthy
5) Start fixing issues from the bottom. With each change, re-assert that the layers below still are hearty.
A typical example would be a long-running sql statement. It would be visible in database monitoring tools, and easily fixed either in the database or by altering the statement. Good.
But it's still a bottle neck. Why? Looking good at the data layer, there may still be issues with transporting the query results to the application server. So, next you look at the database driver, and see that there are a lot of result pagination. You query yielding 20 000 rows gets paginated into 1000 chucks of 20 rows.
So you fix the prefetch size, and now things run a bit smoother. But there's still some issues, because instantiating all of these results can take a while.
So you may be altering the data transfer model to be be more precise of which objects to fetch. But in doing so, you complicate the query again, yielding longer execution time ..
And so on you weave a path upwards to the application level, possibly introducing and resolving several issues as you go. This process is orders of magnitude simpler if you are able to simulate the results instead of actually deploying small fixes to production. In addition, you may unknowingly touch upon stuff that break other performance metrics. So again - monitoring of the entire stack is crucial.
Finally, when you reach a conclusion and have solved all of the current issues - ensure that your current footprint or benchmark is monitored for changes. Future maintenance and development will surely introduce new issues. Get at them early instead of letting them grow and interweave with each other. Then your next job won't be untying complicated knots of system behavior.
lørdag 2. april 2011
Grill-pizza på steinplate

Av og til oppdager man ting som er så fantastiske at man lurer på hvordan man ikke har oppdaget dem før. Igår hadde jeg en slik opplevelse, takket være en gammel steinplate som fikk plass inni grillen.

Pizzabunnen som ellers blir litt kjedelig i ovenen ble helt eksepsjonell i grillen. Og det hele var enklere enn svint: fyr opp grillen til ca 250 grader, forvarm steinplaten, kjevle ut deigen og stek den i 2 minutter på hver side. Den siste stekingen med litt ost og fyll på, feks creme fraiche, skinke, ananas, basilikum og mozarella. Genialt!
Abonner på:
Innlegg (Atom)






