Build Software systems for clients. Use Open Source Technologies. Adopt Agile methods and tools. Have free pizza for Tuesday lunch. Elder Studios The Media Centre 7 Northumberland Street Huddersfield Yorkshire HD1 1RL T: 01484 483042 E: [email protected] W: www.elder-studios.co.uk F: elderstudiosltd T: @ElderStudiosLtd L: elder-studios-ltd
@ElderStudiosLtd One of our client's system: 1.2 million lines of code. 14 Application Servers. 1 Live Database Server (1 Replicated Server). Ubuntu / Perl / JavaScript / HTML / CSS. MySQL Database: 1000 tables, 0.5 terabytes. 3+ terabytes of other files (in ~30m files).
our world: We develop, then we deploy. So our development platform must match the live platform … … but this can be kind of hard to test. And moreover: Some of our developers prefer Mac … … some prefer Linux.
Use a VM for development … if you break it, so what? Install, tinker, play, tweak, all safely. Run a Linux VM on your Windows lappy. $ vagrant init hashicorp/precise32 $ vagrant up https://www.vagrantup.com/ http://www.vagrantbox.es/ $ vagrant init hashicorp/precise32 $ vagrant up
Success implies expansion: In our world, this implies more servers. So you build and install a new server … … but how to ensure it matches the existing servers? Sure, you could login to each one … … but there must be a better way. “Infrastructure as Code”
Manage config of multiple servers from one master server. A “Puppet Manifest” on the master server describes, in code, how a system is configured. Servers “phone home” periodically to see if any changes have been made. If so, the required updates are made. http://puppetlabs.com/
A “real” system has a large code base, so: Multiple developers will work on the same code base. Issues may be being addressed in many parts of the code base at the same time. Developers often do not occupy the same time and space. Bugs can remain hidden for some time. Some sort of control is essential.
A central store keeps all source code. Developers “check out” code … … work on it … … and “check in” amended code for review. “Branches” allow experimentation without affecting the live code. http://gitscm.com/
@ElderStudiosLtd With our multiple developers: How do we ensure quality in the code? (and what does “quality” mean, anyway? How do we enforce standards? How do we stop bugs entering the main system? How do we test the code? What about comments?
attempt = 1; # Assign 1 to variable attempt. # Drunk. Fix later. stop (); # Hammertime! # When I wrote this only God and I knew what # I was doing. # Now only God knows.
twitter @ElderStudiosLtd In the real world: Many developers work on a code base. The code forms the common language. Comments can give a false impression. What if code and comments do not match? def have_stock (stock_item): '''Always returns True.''' return False
doratex
amarelo_n24
frievea
cbtlibrary
.png){kind=avatar}
shuntatoda
yasslab
tsutsumi
matleenalaakso
signer
2720japanoke
jonoalderson
moore
akosma
chriscoyier
addyosmani
cassininazir
.png){kind=avatar}
helenjbeal
frankvandijk
skipperchong
schlessera
swwweet
![[email protected]](https://files.speakerdeck.com/presentations/05ad9b8395b84d84829e1af00f9fbdbb/slide_37.jpg){kind=link}