Search


Categories

Fast Food

Just had the most wonderfully tasty pasta dinner… I’m not usually a fan of creamy sauces – but this was da bomb! Cooking time, approx 10 mins – which means it beats the socks off phoning for pizza too :)

Serves 4

Chop up three small onions, fry lightly in a small saucepan for a minute or two until softened.
Add 175g pancetta, fry for about five mins, until it all looks wonderfully juicy.
Add 250g garlic & herb cream cheese (think Boursin, although I used Tesco’s “light choices” one), and about 150ml milk – keep heating gently, and stir until the cream cheese melts into the sauce and stops being lumpy.

Put on the pasta at the appropriate point – at the beginning if it’s dried pasta, or while the pancetta is frying if it’s fresh pasta – so that it’s done at about the same time as the sauce.

Drain the pasta, mix in the sauce, and tasty’s your dinner :)

Joost Great!

Later on today, I’ll be going to Trinity to pick up the DEPFA prize. Until then, it’s a normal workday… It’s not quite normal though – although I graduated months ago, there’s a sense that getting the prize will truly be the final word in that chapter. And while working at a startup brings plenty of trade-offs, I’m having a fantastic day today :) So I thought I’d catalogue some of the things I love about my job, and a little bit of how they relate to my education.

  • I’m working with truly outstanding, top-of-the-line people, every day. When I started university, I was told I’d be lucky if 1/3 of my lecturers were superb, 1/3 were adequate, and 1/3 were awful. I think that ratio probably panned out over the years – some were better than others. At Joost, there’s just so much talent, everywhere, in all kinds of fields. I don’t know everyone in the company, so I’m sure there are Regular Joes hiding somewhere – but the ratio of brilliant:regular colleagues is pretty high.
  • The job-spec is a springboard, not a box. One of the things that I loved about the IB was that the syllabus was meant to be a starting point, not an end. Only once in Joost have I come up against an “it’s not your job” barrier, and there were real, technical reasons for it.
  • Flexibility is the reality, not some marketing blurb. I have a desk, in an office, on our office plan. There’s been a bit of movement recently, so I’m not exactly sure which one it is, but that’s not the point. When I go into the office, I head to where my team are, and I take over their couch. If anyone minds, they haven’t told me yet. I’m most comfortable working with the laptop in my lap, on either a low couch or a cushion on the floor – and that’s just fine. I get the odd “are you honestly comfortable there?”, but no one’s told me “you have to go sit at a desk”. Not once. This is an ultra-big-deal for me – flexibility has shaped my decisions for almost a decade, and it’s often seen as something one should “grow out of”, move on from. I chose the IB in part for its flexibility, I chose my degree almost entirely for its flexibility, and I have no intention of taking on a job where they tell me how to dress, what time to take my coffee break, or which way I should sit.
  • There’s no “ism”s. I was asked a few tenuously-legal questions at interview, which did shake me up a bit. But despite that, Joost has an incredibly open and tolerant work environment. There’s fantastic diversity in the workforce – and yes, I think it makes the company better just by being that way. People from different backgrounds – culturally, politically, socially, technically – think differently, and that benefits Joost enormously.

I’m sure there’s more, but I’ll save them for another day. Too much cheer all at once could be dangerous ;)

Geek Girl Dinners

Having been invited to a couple of these in far-off lands (ok, maybe not that far…), I was delighted when an invite to an Irish Geek Girl Dinner landed in my inbox.

It’s definitely not invite-only, so if any of you ladies are interested in joining some self-identified Geek Girls for dinner on 27th February, head over to the Irish Geek Girl Dinner website to register!

Guys, you’re welcome too, but the official policy is that you should be invited by a woman who’s planning on attending – the idea being that the attendance is kept to people who want to be there because they’re actually interested in the organization. If you’re genuinely interested, I’m sure there won’t be a problem finding you an invite ;-)

The words of the prophet...

This content is password protected. To view it please enter your password below:

TLDs with MX records…

Stephen’s recently been questioned a bit about his email address validation regex – which has a few problems… Notably, it doesn’t allow for addresses like rob@uk, which I’m assured once existed (although I don’t believe it still does).

He wasn’t aware of any TLDs with MX records – so, of course, I had to set out to make a list. And here it is! The following TLDs (all ccTLDs, though I checked all the gTLDs I could find too) all had MX records, as of tonight :)

.ai – Anguilla
.as – American Samoa
.bj – Benin
.cf – Central African Republic
.cx – Christmas Island
.dj – Djibouti
.dm – Dominica
.gp – Guadeloupe
.gt – Guatemala
.hr – Croatia
.io – British Indian Ocean Territory
.kh – Cambodia
.km – Comoros
.mh – Marshall Islands
.mq – Martinique
.ne – Niger
.ni – Nicaragua
.pa – Panama
.td – Chad
.tk – Tokelau
.tl – East Timor
.ua – Ukraine
.va – Vatican City
.ws – Samoa

Quote of the day!

From Ronan Kirby’s write-up of Skycon, about my lightning talk at the con:

“Also, if anyone has a tape of this talk, there could be money made selling it to an energy drink company for commercial use.”

Sunrise at Ovoca

This content is password protected. To view it please enter your password below:

The iCal Files – ApacheCon US 2006 Schedule

The speaker notifications have gone out, the schedule is on the website, and registration is open. ApacheCon US 2006 is getting closer, and although I won’t be able to be there (it’s the very first week of college, and I’m hoping to be starting my final year… Aargh!), I’ve once again gone and turned out some iCal files for those of you who will make it (yes, I ought to be packing to move back to Ireland, or writing that darn essay. Mneh, I tell you!).

It’s the same deal as last time, and if you’re bringing an iPod to the conference, I’ve also got instructions for importing the schedules to the iPod, and viewing them thereon.

The whole schedule – warning, this is big, full, and slightly scary looking! There’s an awful lot of stuff going on at the con!

The plenaries schedule includes plenary sessions, lunches, coffee breaks – anything that’s good for everyone, no ‘tracks’.

The tutorials schedule will let you know what’s going on for the first two days, although don’t forget the hackathon, your chance to get some really good work done in real time, with the people you usually have to play cross-timezone email-tag with :)

Like I’ve said before, this is going to be bigger and better than any other con going, so the ‘conference’ days are jam-packed. There’ll be five tracks all week long, and an extra all-Cliff, all-day special on the Friday.

The schedules for these are:

Room 1
Room 2
Room 3
Room 4
Room 5
Room 6

As usual, I’ll try and keep these as up-to-date as possible… If you’re subscribed to the iCal, you’ll get those updates automatically – if you’ve just downloaded it for offline viewing, or your iPod, you may have to resync closer to the con.

Remember to keep an eye on the wiki for things like BoF sessions, and if you’re planning a party, make sure to add it there, so everyone can join in the fun! Enjoy!

PHP/MySQL Best Practices

Laura Thomson came all the way from Australia to present the last talk I went to at ApacheCon – PHP/MySQL Best Practices – and for me at least, it was well worth her trouble. This was originally submitted as a tutorial, and was only converted to a talk at the last minute, so we were really lucky to have her!

Talk-lite – 45 mins instead of 3hrs

Design DBs & apps without big holes
Maintainance

Clear vision for architecture = good
‘Framework’ = trendy buzzword

Everyone has a different idea
Some frameworks lead to bloat, and make it hard to do simple things simple

No paradigm for frameworks = no help with maintainability, transferable code
skills

Have a clear & simple architecture
Easy to add to
Easy to explain to new people
Easy to remember now, and in 2/5/10 years

Database extraction = MYTH!!!
Changing PHP = easy
DB chosen based on features
DB extraction layers inefficient/slow/cumbersome

Data access extraction – PDO
Standardise on prepared statements – MySQL4.1

Templating languages (database extraction & frameworks also) – religious issue

Start simple, can’t help but adding features
Ends up with feature-complete languages, adds a layer of complexity = layer of
inefficiencies, something else to break

ARCHITECT FOR YOURSELF – presume that /you/ will be maintaining this in the
future

Don’t rely on server config – write the most portable code possible (security,
ini settings)

Design with security from the ground up – dispatch architecture = single line of
execution

CODE REVIEW – code quality++, make sure code is developed sensibly

Security audit – particularly with inherited/legacy code

Education, education, education – make it easy to do the right thing

Use error reporting – turn it right up on development servers
Aim to write code that doesn’t throw any notices
Turn error level down, or display_errors off, on production servers – attackers
can use error messages to make better attacks

Education – developers don’t know better
Code review from peer-to-peer, formal code review, mentor junior staff, read
commits
Developer education is a good addition to any security audit

Integrating against external data sources – don’t trust them
Don’t trust them to stay the same, be secure (injection attacks), be there at al
l!

Layer of abstraction++
Web2.0/AJAX/DHTML – JS heavy
Nightmare to debug and maintain

Firebug = God’s gift to JS programmers


Maintainability

Can someone understand your code, change & update it? Can /you/? Can the code be
extended/adapted?
“It’s just a hack” – turns into 10,000 lines of code, go back and look at first
500 – they’re buggy, hellish, breakable

THINK AHEAD

Developer ignorance is a big problem

For small project – write small code, be prepared to throw it away if it turns
into a big project
For big project, DESIGN FIRST

Problems arise when projects grow organically

Self-taught/junior developers aren’t the only ignorant developers
Lack of experience with teams/inability to adapt & be flexible
Lack of experience with developing significant (100,000 LOC) codebases
Lack of experience with someone else’s awful code! – #1 driver for developers to
improve is having to maintain someone else’s code!

Obfuscated code – crossword puzzle anyone?
Poor naming conventions – Hungarian notation = most abused naming on the planet
Abuse of define()
Seventeen layers of handoff
Reimplementation of built-ins/standard library functions – esp array functions
Failure to do /the simplest thing that could possibly work/
Premature optimisation – and it’s practically always premature! Obfuscates code,
usually without a good reason

Failure to comment /appropriately/ – “set foo to true if this is true” +
insanely complicated formula
Inline functions–
Nasty side effects – eg library file that includes executable code
Failure to read & fit in with existing code – use functions already in the code
where they exist

Not just about meeting a coding standard – it’s about THINKING!!!
That said – have and use a coding standard
No need to make from scratch – PEAR & Zend Framework have them. Good place to
start anyway
Use a coding standard from the start – nightmares happen if you try to do it
later!

Make rules awkward/hard to remember = no one will use them
Force millions of tiny files = performance hit
Apps Hungarian = just no
If you want something totally OO, use Java or Python
Formatting – use long form PHP tags
Space indents, or tabs, but everyone should use the same!
Comments – header block!
Single line comments for non-obvious code, TODOs, FIXMEs etc
Coding semantics – declare functions/classes in library files that don’t have
execution side effects
Code should run clean with E_ALL
Don’t use magic numbers, ternary operators, embedded HTML

Version control for anything that’ll take more than one week, one code file or
one developer – and most of those too!
Frequent commits – every conceptual change, additional functionality, every bug
fix should have a commit
Detailed commit messages – trac is a PITA, but trac++ still

DOCUMENTATION – any project beyond a certain size needs it. Organic code–
If you don’t document as you go, you never will
Aim for consistently produced lightweight docs – takes less time (so it just
might happen), and is quicker to read

TRAIN DEVELOPERS – code layout/design, sample code, explainations of
architecture/requirements – FEEDBACK

Hell is other people’s code – legacy code: the ninth circle of hell
You may never read all the legacy code
Parts of it are broken, were never used
If it wasn’t documented before, you never will
If it needs a complete rewrite, you won’t have time
You will have to deal with this. If not today, sometime soon.

Worth spending time to audit documentation, architecture, coding conventions,
what’s used, what’s obviously broken/fragile
Refactor as you go, with a lightweight plan in mind
Don’t get too ambitious

Introduction to WebDAV

I didn’t get back to the room til about 4am today, so I was a bit scared to discover myself actually present and awake at this talk!

Show of hands – not many people using WebDAV

Distributed Authoring & Versioning

Authoring means lots of things, Versioning is a little misleading

Built on top of http – like network filesystem, can be used anywhere

Manage files on website/network filesystem for LAN

From the beginning, Tim Berners-Lee envisioned a read-write/collaborative web
Initially, marketing etc made it read-only, until the 90s, when wikis appeared

Web documents, calendars

mod_dav was 3rd party module for Apache 1.3, has been standard module since 2.0

Amazingly easy to configure mod_dav to create a DAV repository – one setup
directive, one directive to enable it (DavLockDB, Dav On)
DavLockDB maintains lock status of files accessed via DAV – Windows DAV
implementation doesn’t implement locking, limits what you can do when connecting
via Windows
Dav On must be in directory scope

DAV implements methods on top of GET, HEAD etc
‘Limit’ can be used to require authn before using DAV methods – anyone can use
http methods, permission required to use DAV ones

Remember that DAV is running on your webserver! PHP & friends will be
interpreted as normal when you ‘GET’ them
Don’t permit upload of PHP files

Files need to be writeable by webserver user – goes against usual best practice
Possible solution: run a secondary webserver on a different port, which can
write as necessary, and is as well locked-down as possible (minimum modules/no
PHP/low MaxClients/SSL/Authn etc)

All OSX applications are DAV-aware – can r/w to a DAV repository
(Insert sneaky FeatherCast plug)
Network Places/Web Folders on Windows
Novell – NetDrive (no longer available from Novell’s website, Google for it!)
DAVFS is in most modern linux kernels

DAV on Windows is just full of awkward ‘fun’. NetDrive++

iCal – sneaky plug for the ACEU2006 iCal files :)

http://www2.et.byu.edu/~njones/share/outlook2ical/ lets you manually publish an
Outlook/Exchange calendar as an iCal file

phpicalendar++

Subversion uses DAV as the transfer protocol

DAV can replace NFS and SMB to get away from OS incompatabilities/hassle with
filesystems
More secure replacement for FTP, can be used over https too