My wife and I became parents of identical twin girls just over five months ago. We did not have IVF or another form of assisted reproduction, and twins do not run in either of our families. From pregnancy to birth to today, it's been a huge thrill. Below, I'll recount some of the experiences and tips we've picked up along the way.
When you first find out you are having twins, the experience can be quite overwhelming. Becoming a parent – especially if for the first time – can be daunting and exciting enough. With the prospect of two babies, doubly so.
The first thing you will need to find out, is what type of twins you are having, and, if you want, their genders. The two main types are MCDA (mono-chronionic, di-amniotic), also known as identical twins, and DCDA (di-chronionic, di-amniotic), also known as fraternal twins. The former means that a single egg was fertilised and then split. The embryos will grow in separate amniotic sacs, separated by a membrane, but share a single placenta. The latter means two eggs were fertilised separately, which means two sacs and two placentas.
Fraternal twins, as the name suggests, are really "just" siblings that happen to have the same birth date, and fraternal twins can be as different as any two siblings (although they'll be the same age, obviously). Identical twins share virtually all their DNA and should hence grow at the same rate, are (nearly) always the same sex, and look physically similar, although there will be small differences, and they will likely have different personalities (ours do). One of the strangest things about our (identical) twins is that, save from a birth mark, they look remarkably similar, yet everyone says Hanna looks like my wife and Skye looks like me. I can't really explain that.
With MCDA twins, the hospital will want to monitor the pregnancy every couple of weeks. The big worry is Twin-Twin Transfusion Syndrome (TTTS), a condition where one twin takes a disproportionate amount of the nourishment provided through the placenta, which can lead to a miscarriage. It is thankfully very rare, and can be treated if caught early. Hence, lots of follow-up.
There is also MCMA twins, who share a placenta and an amniotic sac. This is very, very rare, but also very dangerous, and the mother will likely be hospitalised for a long time and constantly monitored.
Once you start telling people (generally after about three months), prepare for two questions:
The question everyone will be thinking, though is:
As far as I know, identical twins are accidents of nature (although there are some statistical links to things like the mother's age). Fraternal twins occur when the mother ovulates two eggs at the same time and both happen to be fertilised (by different sperm). This can happen naturally (and is possibly something you can be genetically predisposed to, though again age can be a factor), or through assisted reproduction (not just IVF but also things like ovulation booster shots).
At this point, you'll probably be reading lots about pregnancy. All the usual rules apply: No drinking, smoking, falling over, excessive physical strain, etc. However, with twins, there is one thing you need to get very clear:
Your body is going through something that is was not really designed to do.
You'll have friends who are pregnant with one baby, who'll breeze through pregnancy with a bit of morning sickness in the first trimester and have an altogether great time. You'll have a great time too – pregnancy is a magical experience and something to savour – but the strain on mum's body is immense. You need to plan to take it easy. There is a very real risk of premature delivery or other complications if you don't.
Your second trimester will generally be the easiest. If you plan to do something major like move to a bigger house, do it then. If you plan a 'baby-moon' (you should: you won't have a holiday for a while), do it then too. Some airlines won't even let you fly in the third trimester. But plan a relaxing holiday, not a city trek or something with lots of uncomfortable travel. We opted to travel by train, which was a lot less hassle than flying.
By the third trimester, you should plan to spend most of your time doing not very much. Your body will hurt, and walking will start to become more difficult. Think about how you can avoid a stressful commute if you work (peak hour tube travel is not a great idea), and wear a 'baby on board' button so people know you're pregnant (you can get them from Transport for London, I believe). Others should stand for you. If they don't (on London tubes they often pretend not to see you), give them a kick. You should also expect to be huge. Take lots of pictures. You'll miss the bump when it's gone.
With twins, there is a lot of preparation to be done. Some parents of single babies just figure it out as they go. With twins, that's not a realistic option. Moreover, after the birth, you will be too exhausted to read, organise, shop, or even think very much. Figure out how you're going to cope now and get everything ready in good time to cover you at least the first three months from birth. Do this early, because twins tend to arrive between 36 and 38 weeks, not 40 weeks as with other babies (more on that below), and sometimes arrive even earlier than that.
This is probably the hardest thing to sort out, but make no mistake:
You will need help once the babies are born
One baby: one pair of hands. Two babies: two pair of hands. It is possible to cope for short stretches of time as one parent, and at different ages, the babies will be easier or harder to deal with. But as a general rule, you should try to have help most of the time for the first month or two, then not be alone with the babies for more than 8-10 hours ever until they are at least 5-6 months.
There are a few reasons for this. One is that feeding two screaming babies at the same time is difficult and takes practice. The other is that calming a fractious baby requires you to lift and cuddle him or her, which again takes two hands. The physical strain in general is big, especially if you've had a c-section. There is a lot of lifting, moving, and rushing around. Also watch out for how you lift and hold the babies, as there is a very real risk of repetitive strain injury and carpal tunnel syndrome in your hands and wrists, which will not help the slightest.
Help can take many forms. Your parents are the cheapest and often the best. Neighbours, friends, other family also work.
Nannies are expensive, but often the only realistic long term option. They come in a few flavours:
Other roles like childminders and babysitters don't really apply to very young babies.
In all cases, you need to conduct a search and interview. It is better to do this before birth if you can. Expect to spend some time finding the right candidate, and make sure you check references. It is not very common to find people with twin experience, but this is perhaps not such a big deal: instead, insist on someone with a lot of experience with young babies. You do not want someone who will need to be told in great detail what to do. Finally, if you do get a nanny, make sure you find a person you like. You'll be spending a lot of time with her.
You also need to start planning how dad will help out. In most cases, he will go back to work after a woefully short 2-week paternity leave (there's no double leave for twins). This will be hard for him and for mum. It'll be even more difficult to wake up four or five times a night to feed and then go to work the next day. You should expect this to place a strain on your relationship. Plan ahead now, even though you'll likely throw the plan out after the first week. Also make sure expectations are set appropriately at work. Luckily, most bosses are also parents and will be quite sympathetic. A somewhat more flexible work schedule, no/reduced travel and no expectation of working at home in the evenings (forget about it!) are good places to start.
There's no two ways about it. Having twins is expensive. Accept hand-me-downs and buy second hand where you can. We bought a lot of very high quality clothes, toys and nursery items from second hand markets organised by Mum-to-Mum Net, for example, and found many second-hand items on eBay.
Here are some of the major things you'll need to consider:
One thing to consider is that people will give you a lot of clothes and sometimes toys. Leave the tags on anything you get or buy until you use it – that way you can exchange when they invariably grow out of them before you've used them.
There is no need for baby proofing until the babies start to crawl (which hasn't happened to us yet, though I am terrified of when it does). However, you need to think about your house: where will the babies sleep? where will they play? where will you change them? how will you bathe them? Convenience is a big factor here. You want to avoid having to carry them up and down stairs if you can, for example. Expect your babies to just take over everything (our living room is now 80% play area, our bedroom was an obstacle course of cots and changing table for a long time). It's OK. You won't be doing much that's not baby related for a while anyway.
In the first 2-3 months, you probably want them to sleep in your room, but not in your bed, so you'll need space for at least one cot, ideally two (for when you separate them) in your bedroom. After that, you should put them in a separate room, but use a baby monitor at all times. Twins can generally sleep in the same room, though it's helpful to have the option to separate them (even if one sleeps in the living room, say), if one is unwell and keeps waking the other. That said, twins can often sleep through each other's cries, even if no-one else can.
You should take a pre-natal class. Your hospital will offer them, but look out for the NCT (National Childcare Trust) ones in your area, which are often considered to be friendlier. We went to a special NCT class for twins, run by a local mum who had five kids, four of which were twins (i.e. two pairs), so she was certainly qualified. To be honest, the contents of the course are secondary to the fact that you'll get to build relationships with several other couples who are having babies at the same time as you. This is really important, as even 1-2 months of difference in baby age can make it difficult to relate or be able to organise things at the same time, and you'll really value the informal support network this provides.
You should be aware, though, that the NCT, like the NHS, has an agenda. They want you to have a natural birth, and they want you to breastfeed. In fact, much of what you read and hear is quite dogmatic and can sometimes feel a bit pushy. Everyone has an opinion on birth and childcare, and they will let you know what it is.
You should also read. Some of the books we read which were helpful were:
Finally, speak to your doctor and midwives. You should be seeing them more frequently than other expectant mothers, and they have lots information about the process and about what is happening to your body.
I found this to be one of the most difficult things. You don't strictly need to settle on names until you register the birth (about six weeks after birth), but it becomes a bit impractical to keep referring to them as Twin 1 and Twin 2.
I believe it is important that twins get to develop their own identify. I would pick names that have no obvious theme (like April and June or Holly and Ivy) that will forever make other people think of them and treat them as a pair rather than as individuals. For practical purposes, I'd also avoid having the same first initial.
We used of baby name books, apps and websites, and created a shortlist. We didn't really test them on friends or family, though I know others who have done that and found it useful. I would suggest you don't fully settle on the names until you see the babies in the flesh, though. The names should feel right from the start.
Twins are generally born early. 36 weeks is considered full term for identical twins and 38 weeks is considered full term for fraternal twins. Luckily, the body speeds up the maturation process, and there is generally no problem with delivery around these dates.
That said, many twins arrive even earlier. Of the five couples in our NCT class, only we and one other couple delivered on the planned date, and two of the parents had very traumatic experiences. There is probably nothing you can do to fully prevent premature delivery, but taking it easy during pregnancy is probably a good idea.
The big decision you have to make is whether you want a natural birth or a caesarian section. If you go to the NCT classes, they will push you towards a natural birth. Your doctor may push you towards a c-section. Most twin parents we know have had c-sections. With DCDA twins you'll have a choice provided both babies end up head-down. With MCDA twins you still have a choice, but the hospital's advocacy a c-section will be a lot stronger as the risks are greater.
The reason your hospital wants you to have a planned c-section is that twin births are inherently more risky than a single birth (twice as risky, if you think about it). A planned c-section gives the hospital much more control, and you'll give birth surrounded by multiple doctors and midwives. The timing of this is important, however. You want to wait as long as possible to give your babies the greatest chance of maturing, but not so late that any complications arise or that you go into labour. At this point, you'll have what is (somewhat alarmingly) called an emergency c-section, which is the same thing, just rushed and under more stress (although it may not really be an emergency - it often takes a few hours or even a full day from when the need for one is identified to when it is performed).
You will hear a lot about how natural birth is better: establishing breastfeeding is supposedly easier, some theorise that you'll bond with your baby better after going through the pain of natural birth, and your body will recover quicker. The latter is certainly true - a c-section is major surgery under partial anaesthetic and takes its toll on you. Expect to be mostly bed-bound for a week or so, and to stay in hospital for several nights after the birth.
Whether the other benefits really matter, I don't know. We had a c-section and it was the right choice for us. Speak to your doctor and listen to your instincts. Try not to over-dramatise the impact of the babies coming out a day or two earlier than they would have naturally or play the statistics game. And above all, don't for a second feel any guilt, regardless of your method of delivery. Birth is a big deal, but it's only the first fraction of their lives: it's what comes after that matters.
If you do have a planned c-section, it is a little odd to wake up really early one morning, going to the hospital, and being able to count down the minutes until you will become a parent of two (more?) children. Quite surreal, in fact. The procedure itself is also very strange to be part of. To you, this is the biggest day of your lives so far. To the seemingly hundreds of people who are there (two surgeons, an anaesthetist, five or six nurses and midwives, and probably a paediatrician), this is routine. Everything is very procedural.
You may make a birth plan (a written guide to how you want the birth to take place). For a c-section, this is less relevant. You may ask for things like immediate skin-to-skin contact and for the umbilical chords to be left to pulsate for a while to supply a burst of antibodies, both of which supposedly good for the babies. You should discuss this with the surgeon, who will come see you prior to delivery. However, the only thing that really matters is the safe delivery of your babies, and you will probably find the hospital reluctant to deviate too much from their well-rehearsed procedures. That's probably best.
Once you have given birth, plan to stay in the hospital for a while. There is no rush to go home, and you'll come to appreciate the midwives (who'll appreciate you – twins are special even to them) giving you tips, reassurance and helping with the practicalities of taking care of two babies. We stayed for three or four nights, partly because the babies were slightly jaundiced and needed monitoring, partly because we were overwhelmed and needed the support. Note that dad can't stay overnight and whilst visiting hours are quite generous, they never quite seem enough. The nights can be quite lonely and exhausting for mum, especially when the babies need feeding every hour. My tip: Befriend the midwife on duty.
After the birth, you need to go home. This is logistically quite nerve-wracking. I don't think I've ever driven so carefully in my life, or been so scared. Make sure everything at home is ready. You'll miss the support of the midwives once you're there.
After the birth, there are two support systems in place: You'll be visited by a community midwife a few times to check on the babies and mum. After about a week, the health visitors will take over. They'll come to visit sometimes, and you will take your babies to their clinic to get weighed every couple of weeks. The health visitors are a fountain of information and you can call them if you have any questions. We probably called or saw them once a week if not more in the early weeks.
Finally, a tip: If your twins look very similar, leave the little tags they get on their ankles in the hospital on for a week or so until you are comfortable telling them apart. I don't think you'll ever truly mix them up, but the fear of doing so made me paranoid for the first week. It's not as if they'd ever be able to set the record straight if we got them wrong and never realised.
When you tell people with children that you are expecting twins, they will tell you, rather smugly, to get all the sleep you can get now, because you won't get it later. Irritating as this will be to hear, it is true. Sortof. I actually think you should do as much of what you enjoy doing (so long as it is not too strenuous) whilst you have fewer responsibilities.
Sleep will become a big issue in your day to day life. You will not have enough of it. It is quite incredible how much we need sleep and how we are affected by sleep deprivation. Mum will run on hormones for the first 3-4 months, which will help, but not enough. I think my wife Googled the question "when will babies sleep through the night" (which means, you put them to bed at 7pm, wake them at 10pm or so for a quick feed, and then they sleep until 7am) every night for about six weeks. "Do they sleep through the night yet" will be the first question you ask other parents (even if they have only one baby – baby in the singular will not make much sense to you).
There are two philosophies of baby sleep: baby-led and routine-led. The former means you feed and put to bed the baby when he or she gives sign (baby signs are hard to read initially, of course) and never wake a sleeping baby. The latter means you try to structure their day by putting them to sleep and feeding at regular times.
For twins, I maintain that being entirely baby-led is suicide. I have heard of parents being hospitalised from sleep deprivation.
Consider this: In the first few weeks, a feed can take an hour and each baby needs a feed roughly every three hours. If you have twins and you're breastfeeding, and your twins are out of sync by 90 minutes, mum will have no more than 30 minutes rest. Ever. Twenty-four hours a day. This is no way to live.
Secondly, sleep and self-setting are skills and something babies need to be taught, as is the difference between night and day. Good quality sleep is very important for infant development.
Finally, if you're so sleep deprived you make mistakes (e.g. feed one baby twice and not the other), you're no good to them.
To some (and the NHS) being routine-led is akin to baby torture. The problem is that most of the routine literature is incredibly prescriptive. The main proponent is Gina Ford (who, famously, has no children of her own, though she worked as a maternity nurse for many years), and her books have schedules in them down to 15-minute intervals. Babies are nowhere near that predictable, and it can be quite daunting to figure out what to do when the routine goes wrong.
That said, I recommend reading Gina Ford and the book by Marc Weissbluth. You should try to understand the principles behind the routines, and apply them in your own way. It will not work well in the first few weeks, but it will pay off and it will give you something to hang your day on. A map, even if an imperfect one, to help you structure your day will be very useful. The point is not to let your babies go hungry (never do that!) or to keep them awake so they become over-tired (a recipe for disaster), but rather to teach them how to eat and sleep well by giving some consistency and encouraging sensible habits.
The first 1-2 weeks are actually quite easy, as the babies will generally just sleep and wake for feedings. They'll also sleep through virtually anything, so you can put their cot in the living room and have people around to visit. However, the next few weeks are much harder, because they'll be very unpredictable and give you no other sign than a cry that something is wrong.
When babies cry and there's no obvious physical discomfort, it's usually hunger. If it's not, check their nappies. If they're dry, make sure they're not too hot or cold. Very young babies don't get lonely or scared, though in time that may be a reason too. The Week by Week book is a great guide to when you will start seeing changes in behaviour like this.
Finally, with twins, there is one golden rule: Synchronise. If one baby wakes up and can't be settled down again, wake the other. If one goes to bed, put the other down too. Keeping them in sync is the only way you'll manage to properly look after both and still function. Start early and be consistent is my advice.
We started with routines for real about 4-6 weeks. They started working for us from 8-10 weeks, probably.
A few more tips:
If sleep is your number one concern, feeding will be second. The big choice is whether you breastfeed, whether you do so exclusively, and for how long.
The ideal is to exclusively breastfeed for six months before you start weaning onto solids. Breastfeeding is free (formula costs about £10 per tin, which nowadays lasts us less than a week), easier (no bottles to sterilise or water to boil and cool down), and healthier (babies get lots of useful antibodies).
However: for many mothers breastfeeding is incredibly hard.
It always struck me how strange it is that something so vital to the survival of our species is so difficult. But it is. For babies to latch onto the breast correctly and eat properly without falling asleep requires a complex dance between mother and child. It takes time a lot of frustration to get right.
If you intend to exclusively breastfeed, you need to do so right from the start. We always gave a formula top-up (on hospital advice). Gradually, the top-up became bigger than the breastfeed and the babies stopped taking the breast altogether (bottles are easier to eat from). We expressed for a while and did a mixture of breast milk and formula, and now do formula exclusively. I think this is similar to most twin parents we know.
The breastfeeding brigade will make you feel guilty for doing this. Don't. As with many things baby-related, it's easy to get hung up on things that in the grand scheme of things are not so important. Are your babies healthy? Do they put on weight regularly? Good. Move on.
Breastfeeding twins brings particular challenges. First, mum's breasts will be able to produce enough milk (note: cup size has no bearing on milk production, though some women seem to produce milk more easily than others), as her body responds to the demands of the babies. The more they suck, the more she makes. However, it's a gradual process, and you may need to see your babies hungry or frustrated for a few feeds before production goes up enough in the early weeks. Expect to do very little other than breastfeeding in the first week or so to really get started, and expect some discomfort.
Second, you will probably want to parallelise the feeding so that it takes half as long, helps to synchronise the babies, and is more equitable. Give one breast to each baby and switch between feedings (but not during, as both babies need to reach the richer hind milk that only comes after a while, but not necessarily at the same time in each breast). The biggest challenge is how to hold them. We used a twin breastfeeding pillow – a monstrosity made in China called My Brest Friend – which was pretty good, coupled with a raft of other pillows and devices. Sitting in bed seemed to work best. Getting a baby with no neck control to lie correctly and latch on properly is hard, though, and you'll find it easier to start by doing them one by one across the body. Take off their clothes so their skin touches yours to make it easier. And practice. Lots. We got help in the hospital before we left to get the basic technique, and then spent a lot of frustrated days and nights trying to make it all work.
If and when you bottle feed, there are some advantages to that too. It is often easier and faster to feed from a bottle, and dad and others can help out more easily. It is also less straining on mum's body. For bottle feeding you have two choices: expressed breast milk or formula.
If you choose to express, buy an electric breast pump (one of the weirder things I have ever owned for sure). We know a mother who basically fed exclusive expressed breast milk for three months. She had one baby. The time it takes to express and then feed probably makes this unrealistic for most twin parents, but one or two expressions a day for mixed feeding can be viable.
Formula can be made from powder or served from pre-made cartons. Cartons are not economically viable in the long run, but great for emergencies or travel. You should always have some. Powder milk has to be prepared by boiling and then cooling down water to the right temperature. This can take a while (up to 30 minutes if air cooling, though you can pour the water into a bottle and stand the bottle in some cold water to speed up the process; ditto in hot water to heat if the milk is too cold – we found this easier and less fiddly than an electric bottle heater).
Bottles also need to be washed and sterilised before each use. This can take a lot of time and is not something you want to do whilst the babies are hungry. We decided to buy enough bottles to cover a full day's feedings, which meant we ended up with 16 (we now do only 5 feeds a day, thankfully, but at that time we did 8). Also, buy a tabletop steriliser, not a microwave one (too small and fiddly). Finally, make sure you have the right teats: teats have different flow rates and too fast a flow causes excess leakage and sputtering, unhappy babies. Too slow flow causes frustration and may mean they fall asleep before finishing the feed. Start with "newborn flow" (1 hole) and move to "slow flow" (2 holes) after about 4-6 weeks. We have gone with the Philips Avent range bottles and steriliser.
To be able to make up bottles quickly, we keep a clean, sterile jar of cooled, boiled water that we make twice per day. We also have a set of Tommy Tippie milk powder dispensers that we pre-fill with the right amount of formula for each feeding every night, at the same time that we wash and sterilise the next day's bottles. Making a bottle then becomes a matter of pouring the right amount of water into a bottle and pouring in the powder. We prepare the water part for two or three feeds at a time, and tip the powder in at the last minute. Once the milk has been prepared, it will last about 2 hours before it has to be thrown out.
With bottles made, you then need to feed. Again, you want to parallelise. With two pairs of hands, this is relatively easy. Hold the baby, put on a bib or place muslin cloth under his or her chin (there will be spillage), and encourage him or her to eat. This does sometimes take a bit of coaxing and timing is important, but you will learn your babies' signs soon enough. You tend to become adept at anything you do 8 times a day.
With one pair of hands, you can prop the babies up on on pillows, put them in their bouncers (tip: we use the lowest angle on the Baby Björn bouncers and use the toy attachment as an arm rest), or lie them flat on a play mat. The latter is surprisingly efficient. You then have one hand for each bottle. This does take some getting used to. Timing is important: the babies should be hungry, but not yet so hungry they become fractious. You may need to start with them one by one to take the edge off, and then parallelise for the remainder of the feed.
This can be quite hard, because you will in effect need to choose which baby is most needy of your attention to tackle first, and you may have to accept that the other baby will cry for a while. This sounds sensible in theory, but in practice is is incredibly difficult to listen to your own baby crying. Strength of conviction that you are doing the right thing is very important (the same thing applies when you are sleep training using "controlled crying" – again see the Weissbluth book). You also need to stay calm and positive. Babies sense your nervousness and get very nervous in return, which just doesn't help. The thing to remember is that even if a feeding goes a bit wrong, there won't be any lasting damage. The only time you need to start worrying is if, after a week or so, you go for a weighing and they are not putting on weight. If in doubt, call the health visitors.
It is difficult to give advice to other parents without sounding negative. There are a myriad of pitfalls and challenges. With twins even more so. Whenever I received this kind of advice before our girls were born, I always suspected other parents were trying to tell me they regretted having kids, but were too afraid to admit it to themselves.
However, what they were doing – and what I am doing – was to try to prepare me so that I could better enjoy what is probably the most profound thing that will ever happen to anyone. It is at once so common and so special that it is hard to describe. The challenges are many and specific, so I can enumerate them and try to prepare you. The upside is really only one: they are your babies. Having twins is also incredibly special, and is something not many people will get to experience.
These days, if I wake them from a nap, they slowly rub their eyes and stretch. Then they open their eyes and see me above their cots. And they show me the most amazing, unadulterated and unconstrained smiles. Both of their faces literally glow with pure joy. They are so happy to see me – me. They love me so unconditionally they start to giggle. They love being alive. Even the tiniest things excite them.
There's just no way to prepare you for how good that feels. I've literally shed tears when they achieve something that, really, is not all that impressive, like rolling over after having tried for three days. My wife puts them to bed, exhausted and sick of baby duty, only to spend the next hour looking at baby pictures on her phone.
In fact, if there is one final piece of advice I can give you, take lots and lots of pictures every single day. They grow so fast you won't even know what hit you. You'll miss their tiny, fragile bodies when they are plump and active. If you're ever without them for more than a day, you'll literally see the difference. It's a magical experience, and I wouldn't change it for the world.
]]>A few days ago, Franco Pellegrini posted a short message to the Plone mailing lists about a project he'd been working on in his spare time: an IDE for Plone.
It's impressive.
Check out the video, especially the bits towards the end.
I don't think I've met Franco or seen his contributions before, so this came out of the blue. It's like an early open source Christmas present, one of those moments where you suddenly feel excited just to have realised what others are working on.
The immediate reaction of many in the community was one of astonishment. Where did this guy come from? Many of us wanted to meet Franco, connect him with others who are working on similar things, and encourage his project to reach maturity. There's no better place for that than the Plone Conference, which starts November 3rd.
Unfortunately, Franco was unable to come, as he could not afford the plane ticket, accommodation and conference ticket. Within a couple of hours, he'd had an offer of a free ticket from someone who had bought one, but couldn't come, and a room-share for free. We then suggested he set up a ChipIn to raise funds for the travel.
He did. Within 24 hours, it had reached 50% of his stated goal of $1,500. You can check the progress here and perhaps chip in yourself.
It's stuff like this that makes me love the Plone community.
P.S.
Shameless plug: If you're going to the conference and you're interested in learning how the professionals work with Plone, check out my training course Plone Development Environment and Deployment Masterclass.
]]>At work, we've been playing (literally) with Play! framework, a rapid-development Java (and Scala) web stack. Play! feels a bit like it was written by a Python developer who was forced to use Java. It breaks a whole bunch rules of the Java orthodoxy (through sly tricks like bytecode manipulation), thereby addressing the fact that Java was never really designed to deal with the fluid, verb-oriented world of HTTP, a mismatch that users of Java web frameworks have been paying for over many years. (Java is very good for the unique business logic part of applications in enterprise environments, for middleware, scalable architecture and a whole bunch of other things, just not the web, at least not until Play! came along). I like Play! a lot, in fact, as do several of my colleagues.
One of the signs of a maturing open source community is the emergence of books. Hence, I was excited to hear about Play Framework Cookbook by Alexander Reelsen, published by Packt (who also publish my book; Packt gave me a free e-book copy to review, on the understanding that I'd publish a review here.)
In summary: Great content; mediocre writing. Worth buying, but not the first thing you should read on Play.
In many ways, my criticisms are more to do with the editing than the author. Clearly, English is not his first language, and there are a number of grammatical mistakes and awkward turns of phrase that could have been caught in editing. There are also some silly mistakes, such as syntax errors in the code introduced by whitespace or other formatting issues (I can empathise - the layout process of my book was quite painful, since Python is whitespace sensitive) or version details being inconsistent between example and text (something else I can empathise with - I suspect Play 1.2 was released as the book was written; keeping on the bleeding edge can be a lot of work).
The second problem in my eyes is the fact that this has been commissioned as a "cookbook" by Packt. This is a very particular style that I imagine is quite hard to write for. Each chapter consists (only) of a set of "recipes", all of which have exactly the same headings: "Getting ready", "How to do it...", "How it works...", "There's more..." and "See also". Not only does this break the flow at times, it also feels in places like the author wanted to go into more depth or provide more linkages between the different sections, but was restricted by the format. The way the recipes are grouped into chapters also feels a bit arbitrary.
In other words, this is not a book you read cover-to-cover, and it's not the book you read to get started with Play! framework. I tried to put myself in the shoes of someone who didn't know how the big pieces fit together, and imagined being very confused.
However, that's not actually the point. There is well-written beginner documentation available on the Play! website and elsewhere. This book does a great job of collecting a great many interesting, exciting examples. I found myself flipping through the index, virtually 'dog-earing' recipes that could be useful in a future project. I can imagine this book lying well-worn on the desks of my developers, who would use it as a reference. It's the kind of book you buy once you have some confidence you'll know what to look for.
With better editing/reviewing and some light restructuring, this could be a great book. As it stands, you'll probably buy it because it covers some specific topics you are genuinely interested in learning more about, not because it's going to be an enjoyable read or a great introduction to Play! But with that in mind, I think it would be a useful investment.
]]>Four years ago, I wrote what was then the first book covering the newly released Plone 3, called Professional Plone Development. One of the most popular books about Plone, it has sold around 5,000 copies.
A little more than a year ago, I started work on the second edition, intended to cover Plone 4, which was then nearing beta. I initially expected to spend 4-6 months updating the book. How wrong that turned out to be!
Professional Plone 4 Development is now finally available for sale, in paper and eBook variants. It is much more than just an update of the first edition. Whilst it retains the structure, case study and style of the Plone 3 book, I estimate that more than half the content has been completely rewritten, and most of the rest has been at least partially revised.
In part, this is just a reflection of how far Plone has come since version 3. Plone 4 is a major improvement, and the book has been revised significantly to cover the latest best practice. It is fully up to date with Plone 4.1 and even covers some of what will be in Plone 4.2 (in a way that is compatible with 4.1).
The book is also better simply because I have learned a lot about real-world Plone deployments since 2007. The final part of the book, which covers server configuration and optimisation, is significantly better in this regard, as is the content covering the development environment.
Finally, the new book has benefited enormously from a fantastic review team consisting of Plone rockstars and sages, who have read every line and provided not just corrections and feedback, but also suggestions on new topics to cover. They are:
Specific chapters were also reviewed by Laurence Rowe and Steve McMahon. I am extremely grateful to the entire review team, and to my editors at Packt, Maitreya Bhakal and Stephen Wilding.
You can read more about the book on Packt's book page, but I'll summarise a few reasons why you may want to buy it, whether or not you have read the first edition:
You can buy the book from Packt directly, or (at least for the paper edition) from your local Amazon and many other book retails. I can also attest that the eBook renders well in iBooks on the iPad (you'll need to download it as a PDF and install it yourself). I'm not sure about the Kindle yet, but the first edition is available in the Kindle Store, so I assume this edition will be too in due course.
There will be sample chapter and two free chapters that did not make it into the print edition, covering KSS and Archetypes, available on Packt's website in due course.
]]>Disclaimer: These are my personal opinions. I've neither discussed them with nor run them past anyone else from the Plone Foundation.
Plone has some amazingly mature institutions. Right from the beginning, intellectual property rights have been managed responsibly, and are now owned by the non-profit Plone Foundation. Community members can apply to become Foundation Members, and their case is assessed on the merits of their contributions to Plone. An annually elected Plone Foundation Board represents the Foundation in legal and practical matters, and administers its (limited) funds for things like exhibiting Plone at major events and helping developers afford travel to key sprints.
Recently, however, there seems in some quarters to have developed an "us and them" attitude towards the Board, in particular. This is deeply discouraging.
It is worth remembering that the members of the Board are elected from and by the membership annually. I haven't done any formal polling, but anecdotally, it is the best-respected and most accomplished members of the community who are elected. They then put many hours a week into Board duties for no pay or other reward, simply because they believe the work they do is important to drive Plone forward. We owe them a debt of gratitude for that.
Certainly, the Board is not always perfect. As a youngish organisation, the Plone Foundation is still evolving and learning. But I have no doubt whatsoever that the members of the Board are doing their very best and have only the best intentions. They are not corrupt officials bent on increasing their power. They are not corporate miscreants trying to use the Board to their employers' avantage. They are members of our community, making a contribution that is every bit as important as someone committing code or writing documentation - perhaps more so.
It may be easy to lose perspective and undermine the enthusiasm and determination of the Board members. This can range from "stop energy" to downright poisonous behaviour. Examples may include trying to poke procedural holes in minor points to "catch out" individuals on the Board, demanding action that is excessively time-consuming, implying the Board is corrupt, attempting to extract money or personal benefit from Board's or simply assuming the worst about the Board and any of its actions.
The Board are more open and transparent now that it has ever been, and very recently, they announced further initiatives to be even more open. It is good for the membership to join the discourse and query the Board, but we have to remember that this is not state government: these are not opaquely elected officials with lots of power and money to disburse, nor are they elected from an ideologically divided electorate fighting to shape the future of our community.
Rather, the Board members are people that we have elected to carry out boring, but important work for us, the Plone community, for free. We should treat them with the respect and gratitude they deserve, knowing that we have another chance to vote on the make-up of the Board at the next Plone Conference.
For this is what scares me: If we make Board members subject to personal or general attack, or if they feel that their work is not appreciated, they may simply not stand for election next time. I firmly believe that some of the best, most mature and experienced people in the community as presently on the Board, and that they are doing a fantastic job. We should encourage more people to stand, but not discourage existing members from standing again. If we do, we'll have only ourselves to blame.
So, please:
Few things are as precious to a developer as his text editor. I've sworn by TextMate for many years, but recently there's been a lot of rage about Sublime Text 2.
I am currently trialling it, for a few reasons:
I won't say I'm 100% sure yet, but on balance, Sublime Text 2 (beta) feels very solid and is clearly actively developed. I've bought a license and will be using it full time for a while.
So far, there is a lot to like, though also a few things not to like:
I've spent a good amount of time customising and installing plugins to make it work better for me. I'll provide a run-down below, in case others are interested.
This year, I'm giving a training course in the two days before the Plone Conference in San Francisco, on November 1st and 2nd, called Plone Development Environment and Deployment Masterclass.
You can read more about it on the Eventbrite page, where you can also reserve your place. There is a strictly limited number of discounted "early bird" tickets available until August 31st available for $350. However, even at full price the course is a pretty reasonable $395 per person, in keeping with the tradition of offering low-cost, high-quality training before the Plone Conference.
A full description of the course is available on the aforementioned page, but I wanted to use this post to talk a bit about why I wanted to offer the course.
Over the past several years, I've taught a number of people Plone development, both directly through projects at work - often with bright people who are pretty new to Python and Plone - and indirectly, through my book Professional Plone Development (of which a Plone 4 edition is imminent!) and various documentation efforts on plone.org. Through this process, I've come to realise one thing:
Plone development is not hard if you have the right starting point. If your environment and tools are set up correctly, and you know where to look, it's pretty easy to figure out how you should attack a given problem, even if it's something you haven't seen before.
The converse is also true: if you dive into Plone development haphazardly and you don't know how to set up your environments, you will pay the price later. It can be very hard to unpick where you've strayed from accepted best practice and come up with a half-working solution that, in some cases, will be worse than no solution at all because it simply can't be turned into something production-ready. You end up with a soup of code and configuration that you only half-understand, perhaps having copied large chunks from other places.
This course, therefore, is all about setting new and not-so-new Plone developers on the right path. It's about understanding the development and deployment environments your project operates in, installing the right tools - and knowing how and when to use them - and knowing how to help yourself when you get stuck.
The course will be roughly split into two parts: the first day will focus on the local development environment; the second day will focus on the server and deployment. Along the way, we'll discuss common pitfalls, not just those you hit the first time you try something, but also those harder-to-predict problems that only occur when your site has been live for a few months and something goes wrong. Knowing how to diagnose and debug problems becomes essential, especially when a site is live. We'll also discuss performance optimisation, caching and deployment options to make your site not just fast, but flying.
Finally, I want to make sure there is plenty of time for Q&A. The more discussion and experiences shared among the class, the better. I'll do my best to come prepared to answer them. I'll also encourage submission of requests in advance for that reason.
If this course sounds interesting to you, please help us reach the break-even point in time to confirm the venue by signing up as early as possible, not at least to take advantage of the "early-bird" price of $350.
]]>If all else fails, reboot. Or, in the base of a buildout, delete any generated files and start again.
The commands below should remove everything and allow you to run a fresh buildout. Run this from the root of the buildout directory, and don't worry if you get a few "file not found" warnings.
$ rm -rf .installed.cfg .mr.developer.cfg parts/ eggs/ develop-eggs/ $ find . -name '*.pyc' -or -name '*.egg-info' | xargs rm -rf $ bin/buildout -n
Finally, if you are using a shared buildout directory and a previous buildout had network trouble, it's possible that you'll have a partially downloaded .zip or .tar.gz or .egg file that is corrupt and confuses buildout. If so, you can remove the offending file from the dist/ directory in your download cache, e.g.:
$ rm ~/.buildout/downloads/dist/foo.bar.zip
or, if you want to clean up all downloaded source archives:
$ rm ~/.buildout/downloads/dist/*
This should be safe, since any egg that's actually used will have been turned into a .egg file/directory anyway.
Check your ~/.buildout/default.cfg file if you've forgotten where your download cache is located.
]]>I've recently had to step away from a great project – it was difficult to continue after having to leave the country. :-) The project goes live in a few months, but (hopefully) we managed to finished most of the development work.
I can't talk too much about the project itself, except to say that when it launches, it will probably be one of the highest-traffic Plone 4 sites in existence. Moreover, it's a site with long lulls followed by huge spikes in traffic, that needs to cater for both logged-in members of the public and anonymous users, with different load profiles.
I do want to talk a bit about the tools and technologies we used, in the hopes that others will find it interesting. This is easily the most sophisticated stack I've ever used in a real-world project. And on the whole, it's worked extremely well so far.
Beyond myself, the team consisted of two very capable developers with experience of Plone 2.5 and through-the-web development, but limited Plone "filesystem" experience, on a full-time basis. In addition, we had the help of a network engineer and a tester, as well as a peripheral team of testers, trainers and others.
A side-goal of the project was to leave behind tools and working practices that could be applied to future development projects. As such, a lot of thought went into how the development environment was set up and how it could be reused.
We used an agile development process centered around Scrum. To support this, we used Pivotal Tracker to manage stories and defects. This is my third attempt at using Pivotal in anger, and I'm pretty happy with it. Whilst certainly not perfect, it's simple and user friendly enough to fit into my preferred workflow, and it helps the release planning and story estimation process. That, and the price is right.
For source control, we used an internal Subversion server. This was a step up from CVS. I'm pretty confident that Subversion was the right choice: a DVCS would have been far too complicated and confusion-prone for this project.
We installed Trac on our development server as well. We didn't actually use its issue tracking capabilities (since we kept all features and defects in Pivotal), but made use of its wiki and the Subversion browser. I find a project wiki useful for keeping track of "tips and tricks", build instructions, third party contact details and other transient information. I'm not sure Trac was the only (or even the best) choice here, but it did the job. My biggest gripe with it is probably that the wiki syntax is a bit awkward.
Naturally, our development process insisted on having tests for everything. We used Hudson to run the tests regularly and alert us of any regressions. Continuous Integration is hugely important. If you don't have it in your project, get it now. Hudson is easy to set up and flexible enough for all your CI needs.
The last thing to go on our development server was an Apache instance serving a static directory to which selected users had write access over scp. We used this as the release target for jarn.mkrelease when making internal releases of our own packages: The rule was that no production release could contain Subversion checkouts of packages. Instead, we made internal releases to this directory, which was listed in the find-links option in our buildout.
All of our environments were managed with Buildout, of course. To make the buildouts more re-usable and robust, we kept a number of buildout files in a directory called buildout.d. Each file was responsible for building or configuring one aspect of the system. For example, prod-nginx.cfg would configure nginx for the production server, and dev-beaker.cfg would configure Beaker (which we used for session management via collective.beaker) for the development environment. In addition, buildout.d/templates contained templates for configuration files, which were set up using collective.recipe.template.
At the top level, we had the following files:
The top level "environment" files were only allowed to include extends lines to bring in the required components, and settings for host names, ports, users, etc. For example:
[buildout]
extends =
buildout.d/base.cfg
buildout.d/prod-base.cfg
packages.cfg
buildout.d/prod-lxml.cfg
buildout.d/postgres.cfg
buildout.d/postgres-relstorage.cfg
buildout.d/prod-beaker.cfg
buildout.d/prod-instance.cfg
# Hostnames to use for various services
[hosts]
public = www.example.org
master = server-1
slave = server-2
postgres = server-1
# Ports to use for various services
[ports]
instance1 = 8801
instance2 = 8802
instance3 = 8803
instance4 = 8804
postgres = 5432
# Users to run as
[users]
zope = nobody
postgres = nobody
Each file in buildout.d used the the same pattern. Here is an example to build HAProxy:
##############################################################################
# Production HAProxy - load balancer
##############################################################################
[buildout]
parts += haproxy-build haproxy-config
# Configuration
# *************
[hosts]
haproxy = localhost
[ports]
haproxy = 8200
[users]
haproxy = nobody
[downloads]
haproxy = http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz
[haproxy-build]
target = generic
cpu = generic
# Recipes
# *******
[haproxy-build]
recipe = plone.recipe.haproxy
url = ${downloads:haproxy}
[haproxy-config]
recipe = collective.recipe.template
input = ${buildout:directory}/buildout.d/templates/haproxy.conf.in
output = ${buildout:directory}/etc/haproxy.conf
The settings under [hosts] and [ports] are expected to be overridden in the top-level buildout file.
In the development buildout, we installed a number of tools:
We also installed the following eggs into the main development Zope instance:
Finally, we installed Sphinx, which we used to build documentation from reStructuredText files under source control in the docs directory in the build. This is probably the thing I'm most pleased about. We had a rule that no story could be completed without documentation being added to Sphinx. We then set up Hudson to automatically build and deploy the documentation after a successful build. The result is the best-documented project I've ever worked on. Design decisions, maintenance tasks, critical go-live activities and "how the hell did that work again" type documentation all found its way into the Sphinx documentation. Instead of leaving all the docs to the end, we had a continually expanding body of knowledge, and a process to ensure that it was not neglected during busy times of the project.
Each developer's machine ran Mac OS X with TextMate, Terminal and Firefox as the main "IDE". Firebug was of course installed. We used the Zope bundle for TextMate, which includes "pyflakes-on-save" functionally - a big time saver and code quality improver. We also used David Glick's mr.igor to help remember Python imports.
During deployment, we used FunkLoad for extensive load testing. At one point, we had two 8-way/32Gb machines generating load. To facilitate that, we wrote some scripts since released as BenchMaster. If you have never worked with FunkLoad or done proper load testing of your solutions, you're missing out. It's hugely important, and helped us identify a number of bottlenecks and optimisations that would almost certainly have brought the site to its knees in its first week after launch.
We used a number of technologies in the production deployment. Each deserves a blog post in its own right, but here is a quick run-down:
Overall, this project started to "feel right" pretty soon. The development environment and infrastructure held up very well, and was able to accommodate changes both in the requirements and our understanding of the problem domain. Some highlights for me were:
For me personally, this project was a very positive experience. If nothing else, it has taught me a lot of things I intend to put in the book I should be writing an update for right now...
]]>Git is definitely the flavour of the month when it comes to version control systems. In a relatively short space of time, it's attained quite substantial mindshare. I think this has a lot to do with GitHub. And I think GitHub's success has a lot to do with its friendly, inviting user interface. It's a great service, and it's managed to become a de-facto home for Git repositories for a lot of people.
The great strength of Git - enhanced by GitHub - is that it allows people to put up their own repositories very easily. As a developer, I have a natural home for all manner of personal projects, and a great tool chain around them, including a Wiki and an issue tracker.
So what's the problem? Consider this URL:
http://github.com/optilude/some-project
Notice that my (user)name is in the URL.
Once the project outgrows my own tinkering, I may have some contributors, who want to tinker on their own. Git and GitHub encourage this kind of thing. They can fork my project with just one click. But now there are multiple versions of the repository (and the wiki and the issue tracker), and no-one can really be too sure which one to use.
There are lots of potential problems with this, with lots of potential solutions. Let's think about a few scenarios.
Sooner or later, some order has to be imposed on this model. Here, unfortunately, Git and GitHub offer only a handwave. There are a multitude of models that we could adopt. Perhaps we move the project to a more "project-centric" hosting service such as Google Code or Launchpad. Perhaps we set up an "organisation" user on GitHub (but what organisation would that be? for a small project, there may not be an obvious one) with shared ownership, and move our code there. Perhaps we continue with a highly decentralised model, where pulling changes is always an ad-hoc task, and no-one has a stronger claim to ownership than anyone else. There are pros and cons to all of these options, of course, but none seem especially good for a project that has a few users, a well-populated wiki and a bunch of issues in its tracker.
Here's a cautionary tale that happened to me today: I've been using Soaplib, a Python library for building SOAP servers. There was a release on PyPI, but it had a bug that meant I had to get a checkout. The PyPI page listed a GitHub URL, so I used that to clone the repository. A few weeks later, all our builds suddenly broke. The remote repository was gone, deleted from GitHub. Turns out, the original maintainer had given owner responsibility to another person, who has his own GitHub repository. Development had gone on there for months, unbeknownst to me. One day, the original maintainer decided to delete his repository to not confuse people. Noble, but rather inconvenient.
Again, there are lots of solutions to this problem. However, I think that fundamentally, as a user and potential contributor to a library, I want to find "the" repository and commit my changes there. A personal fork is a good idea until I can get access, but there has to be a path for me to get repository access and become a recognised, trusted contributor. Open source projects have used this model for years, as a way to encourage, recognise and empower contributors and build a shared sense of ownership around the project. I expect the project to be bigger than any one contributor or owner, and I expect the infrastructure to be able to outlive their involvement.
This is why, for things that are a bit bigger than one person, and a bit smaller than a major open source project, I've got mixed feelings about GitHub, and even mixed feelings about Git itself. They are great tools. I find myself wanting to use them. But I also worry that they are too flexible for their own good, and that the most obvious way of using GitHub is not a good one for open source projects.
I think Hanno Schlichting put it well: With Subversion, you get a development model, which, whilst not perfect, is easy to understand and has worked out very well in practice for numerous projects. With Git, you're expected to make up your own model. I don't think people are very good at that, and rarely plan ahead for when their code outgrows them.
I know it's possible to use Git like Subversion, with a central repository. But I'm also not seeing a great many people doing that. We have to remember that Git was first built for the Linux kernel, which has a development model unlike most other projects, where it really is up to a set of core maintainers to review every patch and selectively pull it in. They need the kind of flexibility and power that Git offers. For many other projects, I'm not sure this flexibility is always a good thing.
Flame away.
]]>