Today's keynote is about trends that developers across platforms and languages will face.  None of these should be big surprise if you keep up to date and "read the internet".  Presented by the VP of Technology at dzone.com.

• The Rise of Agile and Lean
  • Majority of developers report using Agile, but it means different things to different people - i.e. using Scrum, User Stories, etc.
  • Agile is a hot topic at DZone, so there's an audience looking for help and information on using it.
  • Noticed a rise in consultants and software claiming to help implement Agile.
  • People with small teams/enterpreneurs are the ones practicing agile.  Hasn't broken into "the Enterprise".
  • But, does Agile lead to better software?  Do more frequent releases mean we hit schedules, are more secure,  and solve user problems?
  • More frequent releases DO cut down on having to explain stuff to clients, because you can show them stuff.
• Switch to Standards based Browsers
  • Chrome has had tremendous growth, particularly with technical audience.
  • Windows developers are switching quickly to IE8.
  • Overall developer population is still largely on Microsoft.  But those developers don't go to conferences?
• Everyone needs to know Ajax/Javascript
  • Back end developers need to understand the user interface too.
  • Should learn at least on framework such as jQuery or Prototype
  • Understand how ajax works, and its data transports like JSON, XML.
• Focus on Security
  • Vulnerabilities get more and more media coverage.
  • Are there more security holes or are attackers getting smarter.
  • XSS, SQL Injection, weak passwords, etc...
  • Can't assume your framework takes care of all security.
  • Give equal time to security audits of your code.  Think about security when you're developing.
• Rich User Interfaces
  • Users expect much more dynamic interfaces, even if they prefer style over substance.
  • Lots of options for RIA - Flash, Silverlight, Flex, Ajax, HTML5
  • Must RIAs run outside the browser?
  • it can run on the desktop - what opportunities does this create?
  • Benefits of RIA vs. normal website?
• Mobile and other UI Form Factors
  • Can't presume that everyone has a mouse.  Link targets will have to get larger, more touch friendly.
  • Different platforms have touch interfaces that behave differently.
  • Supporting multiple platforms will be a point of pain.
  • But users expect application to just work.
• Death of Relational Databases
  • Can mean different things to different people.
  • Data store that is focused on horizontal scaling, massive data, and lookups based on primary keys.
  • Large Web 2.0 sites are moving to NoSQL - Digg, Twitter, Reddit
  • But relational databases are not going away any time soon.
  • Most developers are fie on RDMS.  Few need to Scale at this level or deal with massive data storage.
  • Not all queries convert easily.
  • NoSQL data stores very common on the cloud  - App Engine, Amazon SimpleDB
• Distributed Version Control
  • Many choices emerged - Git, Mercurial, Baazar
  • Git seems to have most momentum
  • Adoption driven by Open Source
  • Does anyone still use CVS?
  • Subversion still big, driven by tool support.  Its entrenched in the enterprise because the IDE's have good support built in.
  • Distributed VCS encourages outside participation.
• Cloud Computing
  • What does the term really mean?
  • non-root access on someone else's hosting platform (ie my blog is on wordpress.com)
  • or virtual servers with root access that can be easily replicated.
  • Lot of "Cloud" platforms - App Engine, Azure, VMForce, hosting companies, etc...
  • Hand-in-hand with NoSQL
  • Most apps don't need that kind of scalability
  • Complex systems require more management and automation.
  • Is it worth rewriting our application to run in the cloud.
• Rise of Interpreted Languages
  • Ruby, Python, Clojure, Scala, Groovy
  • New languages to solve new problems
  • Better support for the cloud
  • Take advantage of multiple cores and parallel processing.
  • Often early takers of NoSQL
  • Is the JVM empowering language developers?

I'm attending tekx, and while I'm taking notes in all the sessions with Evernote, I'll try to clean up and summarize my notes here as well.  One of the session's I attended yesterday was Eli White's session on Code and Release management.  It focused more on the techniques, policies, and practices to think about about and implement rather than the nitty-gritty howto details of each version control system.  I found that very helpful because oftentimes its difficult to learn how effectively use version control especially as part of a team's workflow.  Also, its clear now that distributed version control systems have a lot to offer, primarily, and this was my AHA! moment, because they do not impose any workflow on you.  With a central subversion repository, all the developers on a project are forced to work in a certain way.  With multiple repos, you could still setup a central repository for everyone to push changes to.  However, everyone can also have their own repository which I think encourages them to commit and track local changes more frequently.  With SVN, especially as you work on larger teams, its tempting to commit less frequently especially if you don't use branches at all.

• We're talking about managing daily workflow - editing, testing, and releasing
• Have to use version control, there's no way to get by without it.
  • It's a core component, with same core concepts across different systems - checkout/commit/merge/concurrency
  • Distributed is great when stuff will eventually be thrown away, ie for individual experimentation
• Policies - come up with general rules for your team.
  • You need to find rules that fit how you work and how you release code balanced against how you support older code, if at all.
• Use of Tags/Branches/Trunk
  • Trunk - contains core codebase
  • Branches - used to segment into logical areas of responsibility (release/feature/programmer)
  • Tags - mark a specific state of code, a release
• 3 main styles of branching
  • Stage Branches
  • new work is done against trunk
  • branches for staging/production/etc
  • when ready for testing, merge into staging
  • when ready for live, merge into production
  • fixes made into each branch eventually has to be made back into trunk, otherwise your changes may get deleted next time your merge from trunk to a branch
  • difficult to do parallel work (multiple people working on multiple features that may not be released together)
  • Feature Branches
  • New work is done in its own branch.  You never commit to trunk.
  • Easier to do concurrent development.
  • CON - branching might be difficult depending on your VCS.  and you have to do a lot of merging.
  • Release Branches
  • all new work done on trunk
  • create a branch for each version  when ready for release
  • easer maintenance and allows some parallel work
  • little merging
  • assumes that everyone is working towards a common goal / release
  • Pushing code live
  • Absolutely want to have a script - especially if you have a lot of servers.  Use that exact same script to push changes to testing and staging.
  • Have a way to roll it back - scripted and automated.  If something fails, better to roll back and debug in another environment.
  • Live SVN Checkout
    • it works and its simple, so its a very common practice
    • encourages conflicts, especially if some has been editing on live/production
    • hard to automate and difficult to rollback
  •  SVN Export & Rsync
    • use dcn export to make a copy of the code, use rsync to transfer changed files to live
    • simple and easy to scale & automate
    • export gets a copy without .svn directories
    •  rsync is not atomic so some hits might get partiallly updated codebase which is likely to break.

When good document control systems exists, its mind-boggling that anyone still uses network drives to share documents.  While just saving a file is super convenient, you are punting on activities that provide long term value.  These include version control (no more versioning via file names1), retention policies, and better management of the collaborative editing process (who has it open?).

Network drives have never been good places to manage documents, nor will they ever be -- yet that is where most of them sit. It's depressing really, but nevertheless it is reality. Network drives (or shared drives as they are often referred to) give the illusion that you are doing something constructive to store and manage documents, but really they are just dumping grounds, expensive trash cans. The only difference in practical terms is that trash cans actually get emptied at some point. Shared drive trash just grows until they become overwhelming mountains. 

CMS Watch > Blog: Shared Drive Addiction