Christian Peacock

Ranch Hand
+ Follow
since Mar 02, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Peacock


I've been intrigued by Sails in the past, due to my love of Grails, which is similar in concept, and also of JavaScript.

Where do you see the role of Sails.js in a world where the client is becoming heavier and less and less presentation logic is handled by the server? Would it be a good choice to build RESTful backing services for JavaScript Single Page Applications, or is it wasted doing anything less than serving up complete web pages? Does your book cover these subjects?


Campbell Ritchie wrote:Apart from the increased population, for the last fifty years at least there has been a tendency for people to live farther from where they work, requiring much more travelling. Some of that is by their own choice, some forced on them. About 1½ miles from where I live, the council compulsorily bought and demolished several hundred little terraced houses, forcing their occupants to move elsewhere, usually much farther from work.

Totally agree, this is exactly the kind of thing I'm talking about. When I started as a software developer in 1997, I worked somewhere that was about 2.5 miles from where I lived, and often walked. From that place there was a choice of 2 places to go and buy food (not in a town) within 5 minutes walking distance. Now, all 3 of those premises have gone, two of them to be replaced by houses. I now drive over 30 miles each way to work.

Campbell Ritchie wrote:
There is a difference between travelling for pleasure or not, and removing all risk from life. As soon as you start taking risks whilst travelling, you are inflicting risks on others, which is doubtless wrong. Any risks taken to get one's adrenaline levels up shou‍ld be where innocent people and uninvolved third parties are not put at risk.

What I'm talking about with this is not basically the use of public roads as racetracks, but just the pleasure of being in control of a vehicle and the use of skills. I wonder, how many skills can the average person claim to have? And how many might that have been 30 years ago? Many skills are being diminished under the "leave it to the experts" (or machines) mentality and driving is one remaining skill posessed by many that really taxes the brain. We shouldn't be eager to lose the opportunity to have such skills - there is more to life than being safe.
3 years ago
I'm against driverless cars because the problems they set out to solve are mostly just symptoms of the real problems - there are too many people and too many people rely too heavily (through no personal fault of their own) on cars. Most car journeys now are through necessity and by automating the process with no opportunity for manual control, we are surrenduring to this fact and eliminating the opportunity for journies purely for pleasure's sake.

I do not think the human race should continue the pursuit of relinquishing control in the name of safety. There will come a time when everything we do is entirely without risk, or any kind of stimulation and we will then ask ourselves, "What is the point of being alive?"
3 years ago
Thanks Josip. I think if the uptake of Typescript was huge compared to any other JavaScript-based technologies there would be a case for using it over pure JavaScript for me.
That's exactly what I wanted to hear! Personally, I too would rather stick with JavaScript.

Your experience of a contractor leaving behind projects with more obscure technologies rings very familiar...
Hi Bear,

Yes, very good point.

Do you think though that plain JavaScript will remain a popular choice for the developer? Because understanding the underpinnings of e.g. Windows development in the C language was considered important once, but I think I'm correct in saying that almost everyone moved on from C to higher level (and individually more obscure) technologies, built on top of C in most cases, after a relatively short time.

I suppose my question might be better put as "Why do you think someone ought to choose pure JS?" (assuming that you do of course).


Congratulations on the new edition of your book, I've had my eye on the old one for a while!

I think I'm correct in assuming that your book deals with pure JavaScript, devoid of any frameworks? Would you say that it's still worthwhile pursuing JavaScript in its pure form for practical uses, given all the choices such as CoffeeScript and, where concered with browser applications, frameworks such as AngularJS?

I hope the answer is 'yes' as I've kind of fallen in love with the simplicity and power of JavaScript since I started using it in earnest over the past 2-3 years.

Thanks Victor!

I'm really intrigued by your book, it seems like something that I could read cover to cover and thoroughly enjoy - something that I no longer find with most technical books.

To be honest, in my organisation it seems difficult to convince anyone to do anything differently - but it sounds like you have this covered.
4 years ago
Hi Victor,

Your book seems fascinating, and whilst I've always had an interest in UI design, psychology is an aspect that for some reason that I've never considered before.

My questions for you are:

- How can I measure the effectiveness of applying the techniques described in your book? Do you cover this at all?
- In working for a non-software centric organisation, do you have any advice on how I can get others outside of the development team interested in these approaches to design?

Many thanks,
4 years ago
Thanks Sandro, and I look forward to reading your book.
Yes, good point, estimation is the key.

I like the Boy Scout Rule - that's something I've almost always done without knowing it had a name.
These points are well and good if as a developer you're successful in a) providing an adequate estimate for doing a piece of work to a high standard and b) accomplishing that the first time around. If you think to yourself "I could have done that better, and made things easier down the line" how do you justify revisiting a piece of code given that agile mandates you only work on things that are defined within a sprint?

I'm not saying that agile prevents good development but nothing I've heard so far contradicts my belief that it prevents a developer from going back and improving things for improvement's sake.
I've worked with a lot of code written by others that has been of a very poor standard but that did the job, as far as business managers were concerned, perfectly well. The "others" concerned were often well respected by said business managers for getting things done quickly and usually successfully. It's only when another developer such as myself comes along to make changes / fix problems found much later that the lack of code quality becomes apparent. Like I said, in my experience most business managers don't care about the quality of the code - not necessarily intentionally but by the fact that they're perfectly happy with crappy code that they're not aware of and are reluctant to spend money on improving it when informed.

What I meant by agile discouraging craftsmanship, which may or may not be true, is that it doesn't seem to allow time for a developer to improve upon the way that they've done things if that improvement wouldn't be immediately apparent to the business. This is what I would like the author's opinion on.
Hello Sandro,

Your book looks really fascinating, and anything that encourages people to take pride in their work is a good thing.

My question is - how do software craftsmanship and agile fit together comfortably? I kind of see agile as discouraging craftsmanship to some extent, given that all tasks are broken down into small pieces each with a business justification. Surely most business managers do not care about what's "under the hood" and simply want a system that does what they need right now with the lowest up-front costs? (Sceptical maybe, but mostly true in my experience.)


Jeanne Boyarsky wrote:Scrum is supposed to make sure those pieces have business value.

That's the bit that I don't like.... I like to be free to spend a bit of time improving things behind the scenes (refactoring etc) that may / will have value further down the line, but how do you justify this to most business managers?