Port80 2012: Web Project Management
•Télécharger en tant que KEY, PDF•
2 j'aime•844 vues
Taking a big web app from concept to user.
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Port80 2012: Web Project Management
- 1. Web Project Management Taking a big web app from concept to user @Dan_Gates #p80N
- 2. A bit about me Lead Developer at Bite UK Web developing for over 5 years Worked with Sony, Nokia, Logica, Groupon and Microsoft Frameworks of choice are CodeIgniter or Ruby on Rails #p80N http://nokia.ly/HJFOHy
- 3. In the beginning Who is it for? What is the purpose of your app? What will it do? What will it say? What information will it collect? How will it do it? #p80N http://bit.ly/Hih0IQ
- 4. Who is it for? Existing customers? Prospects? Dads? Theoretical physicists? #p80N
- 5. What is the app’s purpose? To make money To get marketing information To make people laugh #p80N http://bit.ly/Iizo4U
- 6. What will it do? Create a photo album from Facebook photos Let people throw sheep at their friends. Make Goofy attack London #p80N http://www.giantsteps20.com/
- 7. What will it say? Consideration needs to be given to what your app will say, and how Don’t overlook success, error and other informational messages #p80N http://mailchimp.com/404/
- 8. What information will it collect? What information does the app need to function What additional information does it (or more specifically, the owner) want? #p80N
- 9. How will it do it? Programming languages, frameworks and Databases Third-party libraries APIs Hosting #p80N http://www.rubyonrails.com
- 10. Costing it up Break the build into bite sized chunks How long will each chunk take to complete? Give yourself a buffer #p80N http://bit.ly/K7GcT8
- 11. Making it pop Hosting infrastructure Database Interface #p80N http://www.heroku.com/
- 12. Hosting infrastructure Client requirements Technology requirements Think about load #p80N
- 13. Database Scalability (where’s my buzzword bingo?!) Availability Simplicity #p80N http://bit.ly/LAh8nG
- 14. Interface Do you need an admin interface? Don’t start with design Guide, don’t lead Be obvious #p80N https://www.wunderkit.com/
- 15. Organisation Project management Bug/issue tracking Don’t over organise #p80N http://basecamp.com/
- 16. Project management Use deadlines, if there aren’t any make them up Build with milestones Have a project lead, don’t step on their toes #p80N http://wrike.com/
- 17. Bug tracking Have a central area to store bugs Post detailed information, not just summaries Assign bugs #p80N http://bit.ly/JORzxj
- 18. Don’t over organise Over organising leeches enthusiasm It wastes time It’s boring Never under-estimate a cup of tea and a quick chat #p80N
- 19. The build set-up Local/Staging/Production FTP Version Control DEPLOY! #p80N http://bit.ly/LAjRNX
- 20. Servers Local server for development Staging server for testing Production server for the users #p80N http://www.apache.org/
- 21. FTP Quick and easy Makes working with a team tricky No change history No way to rollback bad changes #p80N http://bit.ly/M6Qi9B
- 22. Version Control More complicated than FTP Working as a team easier Easy to rollback to last working version #p80N http://bit.ly/J7CyVO
- 23. DEPLOY! Deploy through the shell Write scripts Use tools to make it easier #p80N http://deployhq.com
- 24. Re-use, recycle Dynamic CSS & grids Javascript frameworks Coding frameworks #p80N http://bit.ly/KxPU1H
- 25. Dynamic CSS & grids Save time, reduce repeat code Easier to update styles, built-in responsiveness Show clients results, fast Grids suffer from divitis #p80N http://lesscss.org/
- 26. Javascript frameworks Write complicated Javascript quickly Use pre-made animation code Can you do without it? #p80N http://jquery.com
- 27. Coding frameworks MVC FTW Less wheel re-invention Quicker to build with, easier to maintain #p80N http://codeigniter.com
- 28. Testing the code Be aggressive Use your knowledge of the app Don’t rely on automated tests #p80N http://bit.ly/JXqJUr
- 29. Server watching $ tail -f /path/to/error_log $ top Automated checks Social media #p80N http://bit.ly/JPFEPI
- 30. Debrief What went right? What went wrong? What will you do different next time? #p80N http://bit.ly/KMvGPV
- 31. The End Twitter: @Dan_Gates Web: designed-by-robots.com Web: bitecommunications.com #p80N http://bit.ly/LuyGFG
Notes de l'éditeur
- \n
- > Lead Developer at Bite, a communications agency. I work out of London but we have offices all over the world\n> Developing for 5 years professionally, though I originally started 10 years ago when my school band needed a web site\n> I’ve worked with some really exciting clients, including Nokia, Logica, Microsoft and more recently Groupon and I’ve built everything from HTML emails to huge video management systems\n> As it’s on topic, if I’m given something to build typically I’ll be working with CodeIgniter, although recently I’m getting quite into Ruby on Rails.\n
- > Questions to ask before opening the IDE\n> No different to normal web site, the app needs a purpose and an audience\n> Need to think about what it will do to achieve it’s purpose\n> How will it do this from a technical point of view\n
- > Identify your target market\n> Obviously different people will be attracted by different things\n> Identifying your audience early on will inform decisions later on\n> Make notes about your typical user - how technical are they? What will they be expecting from your app? What kind of language do they use? \n
- > The difference between the app’s purpose and what it will do is simple: the purpose is what you, or the client, want it to achieve, i.e. it’s business goals, what it does is how it will achieve it’s purpose\n> Your app needs to have clear goals to inform the design and build\n> These goals can be used as a metric to measure success (e.g. Client X wants to add 500 emails to it’s mailing list in 6 months, Client Y wants to increase their revenue by 20%)\n> Talk to the client or the stake holders to get these goals so yuou have something to work towards\n
- > So, how will the app achieve it’s purpose?\n> This is where it can get fun and will vary dependant on your audience and the app’s purpose\n> Disneyland Paris raised brand awareness by allowing a user to enter their home address and then, through some Google Maps magic, have Goofy devastate their local area\n> Think Vitamin generates cash by helping developers and designers have fun whilst teaching them new skills and imparting knowledge\n> The app does not necessarily have to be complicated, and should never be more complicated than is necessary.\n> Age old adage: Keep It Simple, Stupid.\n
- > Depending on your audience, and it’s goals, what your app will say and the tone of it’s voice will vary\n> Think about the content, not just paragraphs of text but also the short messages that help out users whilst they perform a task, such as filling out a form, and the messages shown to users if they make a mistake, and when they don’t\n
- > Your app should have a low barrier to entry\n> Require as little personal information as possible, allow the user to give extra information if they want to\n> Trying to get too much information is a bit like being overly familiar with a complete stranger, they need to know a bit about you before they will give you more of their information, it’s the same for app users\n> If the user wants to remove all of their information then let them, if prospective new users find out that you’re storing user details even after the user has closed their account then they won’t sign-up\n> People’s privacy is important, don’t take it for granted\n
- > Consider what technology your app will need to achieve it’s goals\n> What languages will you write it in, will you use a framework, do you need a database?\n> Can you save time by using third party libraries or existing code you may have used elsewhere?\n> Will you need access to APIs? Can they do what you want them to (have you checked instead of just saying yes?) and what do you need to access them?\n> What hosting requirements does your app have?\n
- > Can be tricky to cost out a big app, but there are ways to make that job less daunting\n> Crack out your pen and paper\n> Break the app down into chunks, break the chunks into chunks if you need to\n> Figure out how long each chunk will take to build\n> Add a buffer for unforeseen circumstances, use your judgement on this, I tend to add 10-20% depending on project size and the client.\n> Don’t feel dishonest, you will need it as things you can’t predict will crop up, the client will make changes\n> Get everyone else’s costs (Project Managers, Designers, Copy writers etc.)\n> Get extra costs (hosting, software, API access, service costs (e.g. PayPal))\n
- > More to designing an app than how it looks\n> How it will be hosted is important, someone has to use it after all\n> You also need to think about the database set-up as well as the interface the user will use to interact with your code.\n\n
- > Hosting is often overlooked until the end of the project. This should never be the case.\n> Does the client have any hosting requirements? They may have hosting in place internally, this will dictate what you will use to build the app. Get as much information about their set-up as early as possible so you can address any issues at the beginning of the project, not the end.\n> Corporate IT may place security guidelines on code that they host, so talk to them and make sure you know what’s expected of your code\n> What will the app require to run? This will most likely be dictated by your choice of language, as well as the load on the app\n> Try and get an idea of what kind of load the app can expect in day to day usage and also at launch. You don’t want to go-live and then have your servers fall over. Lots of hosts now offer cloud solutions so you can scale your hosting up and down which is great for saving costs and providing a robust hosting environment. \n> If you can’t get useful estimates for expected usage then guess, and then double it. It’ll be better to have more power than you need.\n> You get what you pay for.\n
- > Not going to debate different database systems, just looking at some best practice that can be applied to databases generally\n> Can the database scale to meet your needs? SQLite wouldn’t be suitable for Facebook, nor many production apps, as it’s performance is slower than other database systems and it doesn’t scale well, but it can be nice for development \n> Do you have the expertise to properly configure the database? MySQL is often said to be poor for large apps however if you have the necessary knowledge you can get great performance out of it - just look at Facebook\n> What technologies are available to you? If the client is hosting the app themselves, and their IT guys won’t budge on hosting, you may be stuck with MSSQL. Find this out before you start building, not when you’re getting ready to go-live\n> Keep the database schema as simple as possible, it’ll make management and programming quicker and simpler.\n> As you would with your code, name things logically and consistently. It will save you buckets of time.\n
- > You may not need to design and build an admin interface, you could potentially manage everything through phpMyAdmin or similar. Not relevant if the client needs to use it but if it’s just you then it could save you loads of time\n> Spending ages worrying about how the app will look will slow you down. \n> Why not use a wireframe to build it and then flesh this out later. It means developers can work in tandem with designers (no waiting around), just make sure you have some form of templating system in place, even if it is just PHP includes. \n> Having a wire framed version of the app will also mean the designers and developers can concentrate on how it works and make an interface that compliments this, rather than going back and forth trying to get it right\n> Let the user explore your app, don’t force them to your end goal, help them arrive there, they’ll be much happier and you’ll get better results\n> Don’t hide functionality (unless it’s an easter egg) - Facebook photo albums are a great example of what not to do, trying to edit a photo album is a pain because nothing is clear until you start clicking around and looking under carpets\n
- > As with any project you need to be organised so that the people who need to know can know what the current situation is (is the project on-time, has the bug the client reported been fixed?)\n> Depending on your working environment you may have a dedicated project manager to handle this, though even if you don’t you want to be as organised as possible without spending more time organising than you do actually coding\n
- > If you don’t have deadlines you won’t get it done as the project will always get sidelined in favour of other projects that do have deadlines, if the client can’t give you any specific deadlines make some reasonable ones up and stick to them, this way the build will progress and when the client inevitably asks if the project can be ready tomorrow you have a chance of saying “yes”\n> When planning the project set milestones of progress you want to have been made by a certain point, this will mean you can see early on if a project is falling behind schedule and account for this\n> When you’re planning your milestones ask your developers what’s reasonable, don’t just drop unfeasible milestones in their laps, get everyone involved\n> Even if you don’t have a dedicated project manager have a project lead who will act as the central point for client communications and making sure everything is on-time\n> Once you have a project lead don’t start crossing over your work, if you both start communicating with the client and managing portions of the project everything will get confused. Let them do their job, you do yours and vice versa.\n
- > Store bugs in a place where everyone can see then, not just a post-it note on your desk\n> The place where you store them doesn’t need to be a fully fledged bug reporting tool, something like Wunderkit could work just as well for in-house collaboration\n> When reporting bugs write something in addition to a quick summary. Describe what you were doing, and where. Exactly what happened, what error messages appeared. Details help isolate the problem quickly, saves time\n> Assign bugs to developers to be fixed, if you don’t “tricky” or annoying bugs that aren’t easily fixable won’t get fixed\n> Assign bugs to those they most apply to, if the bug applies to a portion of the app that a specific developer created assign the bug to them as they’ll likely be able to fix it quicker\n
- > It’s easy to go from lack of organisation to too much and both are pretty bad places to be\n> As a developer I want to develop and make cool things, I don’t want to have to have endless catch-up meetings, fill out progress reports, update progress trackers and on and on. \n> Making me do that leeches my enthusiasm and my code will be worse and I’ll be demotivated and grumpy\n> It’s also a waste of time, it just isn’t necessary and it’s really boring\n> Sometimes you will have to fill out a progress reports of different kinds, and that’s fine, but it’s not necessary everyday\n> Why not have a cup of tea and a quick chat with the team in the morning. You’ll be up to date quickly and you might just have a laugh doing it.\n
- > How you set-up your project can mean the difference between disaster and success\n> A good set-up can help make build easier, especially in teams\n> It can help find bugs early on and prevent them from making it onto the live app\n> When bugs do crop-up it can help you mitigate the damage quicker\n> Keeping your set-up consistent will make it quicker to get going in future as you can create templates and shortcuts\n
- > Have a local server, either on your dev machine or on a separate machine. \n> Having the server on your dev machine is cheaper and easier to set up, you can either use something like MAMP or XAMPP to do it or for you or set it up yourself\n> Mac’s have Apache and PHP pre-installed, for instance, and with a bit of configuration it can make a good development environment. After you’ve set-up Apache use Homebrew to set up MySQL and you’re away\n> Having it on a separate machine means you can closely mimic the Production environment which is handy for finding bugs that may only occur on specific environments, or with specific configurations or software versions\n> A Staging server is where the code goes before you make it live, it’s an important step in the testing process\n> It allows people who don’t have access to your local dev environment to test the app\n> The Staging server should be as close to identical to your Production environment, typically with lower specs\n> The Production server is where all the live code goes, only code that’s been thoroughly tested should be put on here as it’s where your users will be using it\n
- > FTP may look quick and easy but it poses problems on bigger projects, or projects with more than one person working on it\n> As there’s nothing to check conflicting changes work can be lost and bugs can easily be introduced\n> This can be overcome by talking but there’s always human error and forgetfulness to scupper that one\n> There’s no change history, you can’t easily see what’s been changed and who’s changed it\n> If some bad code makes it on to the server there is no easy way to rollback - you have to hope that you either kept an old copy or your IDE has some pretty clever undo capabilities\n> Storing your code on DropBox can help with this but it’s not particularly elegant and by no means foolproof\n> Usually OK for smaller projects, like a quick web site build, not suitable for big app builds\n
- > Version control has a learning curve associated with it, and documentation can be a bit sketchy when you’re getting started\n> Lots of kinds to choose from - Git, CVS, SVN and Mercurial for example\n> Will make working as a team safer as changes can be merged and you can see who has changed what, and when\n> Easier to keep everyone’s code up-to-date and in sync\n> If some dicey code does make it onto the Production server it’s very easy to rollback to previous versions whilst it’s fixed\n> Tools are available to make working with version control a breeze - GitHub has a nice GUI available, Git Tower is also available and much more powerful, although not free like GitHub’s GUI\n> If you’re building a big web app, even on your own, it’s a must, it’s much safer and more flexible than FTP and the code history can be really really handy\n
- > Three options when deploying the code to a server - you can manually do it through the shell, you can write scripts to do it for you or you can use third party tools that will do it for you\n> Doing it manually will give you a better understanding of what’s going on, and it never hurts to have some extra knowledge for when things go wrong\n> Writing scripts to do it for you is also a good way of learning the ins and outs of what’s going on, you’ll still have to do some bits manually though\n> Using tools is quicker, and it makes rollbacks as simple as a click\n> I started off doing it all via the shell but moved to using a tool (DeployHQ) as it was simpler to manage lots of projects through it\n
- > There are lots of tools you can use to make your life a little bit easier\n> Making use of existing code means you don’t have to keep running up the same hill\n> Usually means including lots of unnecessary code, though if done right this need not be a problem\n
- > So we’re on the same page, Dynamic CSS is CSS that is built with something like LESS or SASS and a grid is a CSS framework like 960.gs or CSS Grid\n> Using Dynamic CSS, a CSS grid or both can save a lot of time messing around with floats, positioning and margins\n> It can also make getting the bare bones responsive site off the ground if the framework comes with that\n> Dynamic CSS makes updating styles a lot easier by using variables, mixins, functions etc.\n> You can pull together a basic example of how the site will look in a browser quickly, handy for designing in the browser and giving a client realistic expectation of browser inconsistencies\n> CSS grids suffer from having to use a lot of divs and classes. This will make your source less pretty and less semantic. It’s a trade off with time\n> The grid can be used as a prototyping tool, however, and then more efficient HTML and CSS can be written after, assuming you have the time and budget\n> Make sure you compile your Dynamic CSS on production sites. CodeKit is really excellent for working with it and compiling automatically so even in development environments you can use the compiled CSS rather than the development code making testing more accurate\n> Personally I don’t mind using compiled Dyanmic CSS and CSS grids on production sites, but people’s opinions will vary greatly on that\n
- > Javascript frameworks can take some of the coding strain and save you time by giving you access to pre-written code\n> This is especially useful for animations, and UI flourishes, jQuery UI takes care of a lot of the common UI extras like colour pickers and jQuery Mobile does the same for touch devices\n> jQuery has lots of libraries available for free, other will do as well, I’m only concentrating on jQuery because that’s what I know\n> Don’t always assume you need a Javascript library, you can reduce HTTP requests and load times by writing your Javascript without it, this is especially important on mobile connections\n
- > Coding frameworks are great, using one means a lot of frequently used code, like database connections, won’t need to be written by you, so you have more time to build cool things\n> They help keep your code nice and structured, the Model View Controller model keeps everything separate and contained which makes programming much cleaner and much easier to come back to later\n> The downside to that is they can be inflexible and force you to adopt their programming style, however doing so means that other programmers who come on in a project later will be familiar with how it’s been written\n> Code you have previously written can be used again, CodeIgniter libraries, for example, can be used on other CodeIgniter projects with little, if any tweaks, third-party libraries can also save you time\n> Some frameworks even take care of the really boring stuff, like data validation, Ruby on Rails is great for this, but other frameworks do it too\n> The added code organisation will make re-visiting code written in the past much less painless, and make adding new things simpler\n
- > The whole point of testing is to find breakpoints and bugs so try and break the app, don’t be shy\n> Enter random data, SQL strings, PHP and Javascript code, as well as any other languages that may help break the app, do things that you would not expect to happen in the app’s lifetime, users are unpredictable things and they won’t go easy on your app, so neither should you\n> Block access to dependencies (MySQL servers, CDNs, APIs)\n> Use your knowledge of the code to find ways to break it, or even to hack into it\n> Use automated testing, such as in Ruby on Rails, is great but don’t rely on it, there’s no substitute for good old fashioned human error and ingenuity\n> Always assume the worst thing that could happen will, don’t take things for granted\n> Write code defensively\n> It’s better to display an error message than a white screen of death\n> Don’t forget to log issues you find in your bug tracker, and then fix them\n
- > Watch your error logs live - if you’ve done all your build and testing right normal usage should cause no errors so if they start appearing you know you’ve got a problem\n> Keep an eye on your server usage with top, assuming your server set up makes that useful, watch for CPU and memory usage and anything else that might be a cause for concern\n> Automated systems such as Pingdom are useful for alerting you to downtime, though they aren’t 100% accurate, for example white screens of death will show the server as up, rightly, but the app is down\n> Try checking for a string in a page’s HTML to circumvent this\n> Watch Twitter, if people are talking about your launch they’ll talk about any problems they’re having and Twitter is the fastest way to find out about this stuff, especially if problems aren’t showing up in error logs as they’re bugs, not errors\n
- > When the project is live and the dust is settled head to the pub to relax and un-wind\n> Talk about the project, hindsight is a useful thing so make use of it\n> What parts do you think went really well?\n> It’s easy to dwell on what went wrong but you should always take time to congratulate yourself on things you feel especially proud of and things that went well\n> You do need to look at what went wrong, how can you avoid it next time? Do more research? Allow for more time?\n> Finally, if you were going to do the project again what would you do differently? Don’t just think about how you would avoid mistakes, what would you change about the things that went right? Would you work together differently, or build the app in a different language?\n> Your looking back will make your future projects even better, treat every project as a learning experience.\n
- > Thank you\n> Feel free to come say ‘hi’ and ask any questions, and if you’re look for a development job in London make sure you come find me as we’re looking to recruit a new one to join the team\n> Time for Qs?\n