The iPad and iPhone has more than a few quirks web developers need to handle. One of them is being quite insistent on when to show and hide the on-screen keyboard. The default iPad behaviour, in all iOS versions, is to drop the keyboard between input fields, and to deny programmatically showing the keyboard on focus changes. It is only shown when the user taps an input field.
While this is adequate for most situations, it can be really frustrating in cases of several fixed-width input fields in a row.
Here is how to circumvent this behaviour and give your site’s user interface a more natural flow. This solution works for wide and short input fields alike, flawlessly moving the user from zipcode to phone number, or from character to character between multiple single-letter input boxes. Compare entering words on lexical word finder (without this technique) to entering words on this wordfeud help site (with this technique).
We rely on two tricks to make this work. First, we keep the user in the same input box all the time, just changing the position and appearance as we move along. Second, to keep the code changes small and localized, we take advantage of the fact that we can change the
id of an element.
In this way, even as we are moving the same input field along, we are changing it’s
id (and size, location etc as well) — to avoid having to change the existing program logic of the page. The entire time, all input fields will have the correct id’s, even though we have been moving the same field along all the time. We also do not introduce any extra fields to put above the real/existing ones (a trick seen in some other solutions).
This has the additional advantages of always leaving the page in a consistent state should the user choose to unfocus and do something else in the middle of filling out the form, as well as being supported in all browsers – avoiding an iOS-only workaround.
The code snippet with a live functioning demo is hosted on jsFiddle.net and should be fairly self-explanatory. It shows both the regular and iOS-friendly version.
Most of the magic lies in replacing the common step
nextfield.focus(); to move from one input field to the next, with the function
moveon_ipad(fromfield, nextfieldid) and realising that there is no previous field to blur (i.e. removing any blur-specific code when moving along, although it stays in for the event when the user clicks elsewhere).
In the demo, each field has a different background colour to allow you to see how the field moves along in the iOS-friendly version while they all stay put in the plain version. In practice, the background colours would be the same (or one of the properties the moveon_ipad function swaps), so the user would not notice any difference.
While the live demo uses jQuery1.9.1, the code is very short and easily adaptable. The demo also uses absolute positioning to ease the movement, but this is not a requirement.
Det er vinter og tid for karamellpudding. I år lages den sous vide. Det er foreløpig vanskelig å finne konkrete fremgangsmåter på web, men fortvil ikke, etter litt prøving og feiling er oppskriften her — og resultatet blir perfekt hver gang. Oppskriften fungerer også fint for vanlig ovn.
For 5 personer trengs:
3dl sukker til karamell (blir mer enn nok)
1dl sukker til pudding
Men det kommer som regel flere, og alle liker karamellpudding, så jeg lager dobbelt opp. Karamellpuddingen lages like gjerne av laktoseredusert melk og laktosefri fløte.
Karamell er varmt og karamellpudding krever flere omganger med oppvarming og nedkjøling. Dette er en kjempeanledning til å skaffe litt utradisjonelle kjøkkeneredskaper som sveisehansker og IR-termometer.
Steg 1: Karamell
Mens man før trodde sukker smeltet, så har man nå funnet ut at smeltende sukker har en prosess som ligner mer på nedbrytning og som foregår i området 160-185°C. Rask oppvarming gir et høyere smeltepunkt enn sakte oppvarming. Dette kan vi utnytte for å få perfekt karamell. Ved for høy temperatur blir karamellen mørk, brent og bitter. Bruk svakere varme, god tid og få den lysere brun og tyktflytende. Noen små klumper av sukker gjør ikke noe, de løses likevel opp senere i prosessen, men sjekk at det ikke er store klumper av sukker igjen i blandingen.
Bruk en sleiv til å smøre karamellen rundt i formen. Her bør det gå fort, for karamellen stivner raskt. Sveisehanskene sørger for at ingen brenner seg selv om karamellen er varmere enn kokende vann. Man kan ordne seg litt bedre tid ved å forvarme formen. Få karamellen opp langs kantene, men det er ikke viktig akkurat hvor langt opp den kommer.
Siden jeg lager dobbelt opp blir det to brødformer.
Steg 2: Pudding
Kok opp sukker, melk, fløte og vanlijestang i en gryte. Som alltid ved oppkok av melkeblanding så brenner det seg fort så rør ofte. Automatisk sauserører gjør jobben og avlaster kokken.
Etter et kort oppkok må blandingen avkjøles. Mens man venter passer det å røre sammen eggene.
Blandingen må være under 60°C før eggene helles i for å unngå at eggene koagulerer.
Steg 3: Blandings
Så er det bare å helle i formen.
Og plassere i maskinen. Plast på toppen gjør at det ikke regner på puddingen fra taket av maskinen.
Melkeblandingen hever koaguleringspunktet helt til 79°C. Vi må derfor over 79°C for å få blandingen til å stivne. Jeg bruker 83°C i 2t 10min. Det betyr ikke så mye om vannbadet er forvarmet eller ikke siden ingenting stivner før 79 grader likevel, men tiden regnes fra maskinen når riktig temperatur.
Går man for ovn plasseres formen i vannbad også der, men da 125°C i 2,5t. En fordel med sous vide er at man unngår den snerkete toppen (som blir bunnen ved servering) på den ferdige puddingen.
Selv om det ser elegant ut med form som flyter i maskinen, så lønner det seg å tilpasse vannmengden slik at formene står selv. Når puddingen stivner kan det nemlig hende det ikke skjer like raskt over alt. Dermed kan formen ende med å stå høyere i den ene enden underveis i prosessen og vips tar den inn vann og synker. Er du heldig skjer det ikke for tidlig og man kan bare helle av vannet.
For at formene skal kunne stå, men maskinen likevel ha nok vann, plasseres noen avstandsstykker i bunnen. Til overs IKEA-vinkler fungerer fint. Uten nok vann i maskinen vil den ikke klare å holde temperaturen jevn.
Den ferdige puddingen avkjøles og settes i kjøleskap ca ett døgn — gjerne lenger. Løsne sidene fra formen før servering, hell av karamellsaus i mugge, og snu formen raskt på et fat.
Serveres med pisket krem! Nyt den!
Intel is pushing a new form factor, the Next Unit of Computing (NUC), and it is looking good. I recently got two of these and have some pictures and experiences to share.
The NUCs have some exciting properties and a couple of gotchas, read on and avoid my mistakes.
First of all the box itself has a small surprise. When it opens it plays the Intel jingle from some embedded electronics with a light-sensor and a speaker. Oh, the humanity.
Inside the box is the power supply, the surprisingly small unit itself and a solid metal bracket (and six screws for this). The bracket is a VESA mount used for hanging the NUC on the back of a monitor. This is a very clever way to get the unit out of the way and put all those monitor VESA mounts to good use.
What is not inside the box is:
- Power cable (from wall to power supply)
Also, while having two WLAN antennas inside, the unit does not contain a motherboard with onboard WLAN.
Note that due to the crammed space inside, the parts are as small as possible. If you want to get a suitable WLAN adapter, make sure to get a PCI Express half mini adapter such as the Intel Centrino Advanced-N 6205 (top left).
And most importantly, the disk is an mSATA (lower left), an until-now quite unusual form factor and currently only available as SSD. My usual webshop does not yet even have a category for mSATAs, they are hidden amongst ordinary SSD SATA drives, which caused me to actually order the wrong drive the first time around. The brick-and-mortar stores in my city does not yet stock mSATAs at all.
This particular NUC boasts an impressive amount of display IO for the small size. Two mini display ports in addition to HDMI is not commonplace. Apart from this there is ethernet and three USBs (two shown here and one available on the other side).
All NUCs restrain themselvs to Intel onboard graphics. While models with HD5000 are on their way this month, only models with HD4000 are actually in stock right now.
I really like the monitor mount. The NUC is not screwed in place, merely hinged on to the metal bracket, but fits snugly. The end result is a stationary computer without the usual space-consuming tower to hide.
Functional Programming, as a paradigm, does not have users, it has devotees. I am myself one of those, spending time in Haskell as often as I can.
Why then, if it is so great, has FP not taken over the software development world?
There are many answers to this question, ranging from the condescending (“is hard”, “has no practical use”) to the hopeful (“just haven’t reached critical mass”). This post is about another, often overlooked, fundamental reason:
Most programs are mostly about I/O
Corporate programmers, in flavours of start-up to enterprise, mainly spend their days designing software that takes user input, moves it over the network, stores it in a database and even has the ability to fetch it back again. The furthest you get into processing data on a typical day is perhaps report generation. Then, outside of your main project, your build, deployment and test scripts are all about I/O as well.
The interesting tasks, such as rendering, query optimization or data aggregation is all handled by platforms or tools. Which is efficient, since those things can be time-consuming to develop, and you are paid by time units.
While the notion that most programs are mostly about I/O seems obvious to the legions of corporate programmers using Java, PHP and C#, it is not to everyone. Runar Bjarnason gave a talk in New York last week on I/O in FP. The talk itself, while great, is not what caught my interest.
Inadvertently, 8 minutes in, he brilliantly sums up the chasm between FP and the real world (for mundane, but very common, variants of the real world) in 32 seconds:
You have some code that interfaces with the outside world, and then you have, like, what your code actually does.
And those things are kind of intermingled.
But in reality, your code is not about I/O. I/O is just the code that retrieves the input to your program, and then takes the output of your program and delivers it somewhere.
And those parts are not really that interesting. Your code is not about that. Your code is about what happens in between.
I have spent years in the corporate world on a multitude of different projects, and quite often not a lot happens in between. While there is a “pure” core of business logic in there somewhere, it is dwarfed by the amount of I/O-related code. Look at a typical mobile app, how many lines of code should have been separated into pure modules?
For this reason, if we want to convey the usefulness of FP to the imperatives amongst us, we need to focus on elegant solutions to real world inputs and outputs. Most software needs to integrate with other software. We need to show how our I/O-libraries, often overlooked or thought of as mere “helpers”, are superior in efficiency and leads to cleaner and more maintainable code. While a pure HashMap is a beautiful thing, let’s focus more of our time on Haskell packages such as postgresql-simple, amqp (of which I am a minor contributor), aeson and the fact that there is no native MSSQL library, just ODBC. Let’s focus on the plumbing, so to say. Great packages for integrating with the outside world is what will bring FP to the masses. When that prerequisite is there, only then are they ready for all the other stuff we have.
And please do not go on and on about the beauty of lens, to the casual passer-by it seems of no other use than to demonstrate that basic functionality they take for granted is somehow missing. If you want to wow someone, instead demonstrate how one line of code adds ekg to your long-running process.
We could be doing our day jobs in Haskell. But most of the FP literature (and a lot of the packages) is focused elsewhere. As it is, one has to excpect or anticipate doing som library work when starting a project in Haskell, I really hope we will get past that soon.
The Raspberry Pi is a versatile and cheap piece of gear. While neat, it has pieces protruding from every side and as it turns out, this made it just slightly too wide for the enclosure I had in mind. No biggie, we can slim it down a bit.
The parts bothering us the most are the RCA connector, the audio jack and the SD-card. This being 2013, we are not going to miss neither the RCA nor the old-school audio.
Pinching the RCA connector to apply a slight pull, whilst applying a soldering iron to each of the three pads several times in a circular order, gives the desired result.
The audio jack has 5 soldered pads, one in the front and four in the back. The finger pull was not enough and I ended up fastening it to a vise and pulling slightly on the PCB.
Voila! Look at that surprised face below the RCA plug.
The next step is the SD card. We can easily get that flush with the edge as well, either by using a custom made micro SD adapter, such as this one, or by using our kitchen scissors. Reddit user divapprove gave me the tip that modern cards are mostly plastic anyway. As it turns out the electronics is all in the top few millimeteres. By snipping away a few millimeteres at a time we can safely adjust the length of the SD card to make it flush with the edge.
All in all this reduces the footprint of a full enclosure for the Raspberry Pi from 111 x 64 (71cm²) to 98 x 56 mm (55cm²).