I will be trying to live blog from the DotCMS Bootcamp conference here.  Watch this space for updates.

Last night opened with a cocktail party for some social networking.  It was great to meet back up with some old friends and meet some new ones as well.  It was kinda sad that a lot of the folks that didn’t get to make it.  We miss you fusion27, bradrice, and all the other folks from the IRC channel that couldn’t make it.  After the party a bunch of us went to Sushi Samba — AMAZING, I really recommend it.

8:30 AM:  Breakfast in the Hotel was nice.  The weather here in Miami is amazing.

9:30 AM:  First Session:  DotCMS Roadmap.

• Tim is up to kick off the session
• Plug for the mailing list and the IRC channel:  #dotcms on freenode — Feel free to join in
• Tim is passing it off to Will
• Jason Tesser and David Tores are co-presenting
• 1.9 …
  • 1.9 Has thousands of improvements over 1.7
  • Expected to ship 1.9 in June/End
  • 1.9 Beta was released yesterday
  • One more big piece for 1.9 … scripting plugin is going to be built into the core of dotCMS:  PHP, Groovy, Python, Server Side Javascript
• What is coming for 2.0?
  • API/DB Updates
  • UI/UX Sugar
  • Enterprise Support
  • Multi-tenant features
  • Marketing Tooling upgrades
  • Revisit Workflow
  • Functionality via modules
• Will passed it to Jason to talk about API/DB Stuff
  • Normalization of Identifier and Tree Tables !!!  his is huge for anyone going straight to the DB for development/searches
  • End of Limits to structures
  • SQL to Lucene Translator — Ability to write SQL against the Lucene Index!!!  HUGE.
  • API Refactoring in Folders, HTML Pages, File Assets — Allow you to write plugins that won’t break from version to version, of course this will break plugins initially
  • Upgrade to Hibranate 3.X and OSGi
  • OSGi –
    • Injecting things into the menus/UI hooks
    • Hot deploy plugins
• Jason Passed to David to talk about UI/UX Changes
  • Front End inline content editing — in place editing!!
  • Simple Content Search —  Think gmail interface, simple, intuitive for users.  Single field searcing, autocomplete, with advanced options of course
  • Better Image tooling — cropping and rotating — for users
  • Continue to make it suck less — yes that is actually a bullet point.  Many small improvements to the UX
  • Better Error Handling and reporting for velocity developers — THANK YOU!
• Back to Jason for Enterprise Deployment
  • Was push publishing – Now called sync engine
  • This is a step towards this
  • Having multiple live servers and keeping them in sync
  • The code is there for this in 1.9 — but the tooling is not done
  • This is not so much pushing dotcms content to an IIS server as dotcms to dotcms (this is what CMIS for)
  • Staging > Live system
• David on Multi-Tenant
  • Becoming your own onDemand CMS Provider and maintaining control — divide websites between clients
  • Delegated User Management
  • Putting Users on Hosts
  • Cloud-Based Mega Deployments — Need a new instance or more power for a new client, just add it via cloud computing ALA Amazon EC2
• Jason for Marketing tools
  • Currently it sucks
  • Retooling the eNewsletter process to utilize 3rd party SMTP services
  • Separate users from customers
  • Users as content types – extendable and flexible — powering the developer
  • Tools for browser compatibility and 404 checking
  • HostWatch dashboard – aggregating analytics internal or external across your sites
• David for Workflow
  • currently workflow is not powerful enough
  • Not doing things like JIRA, more tied to the website
  • 1 click default actions for all the tasks that are currently tedious
  • Batch Actions — Publishing/Reviewing multiple objects at the same time
  • Multiple Approval Steps — Not rule based, but allowing for multiple steps instead of just one approval
  • Better emails for workflow that allow you to take action directly in the email instead of having to log in
  • Preview Token – viewing staged content without logging in
  • Don’t bog it down with complexity — keep it simple but extend the functionality
• Will is up for the Enterprise Modules
  • Some of the things they are working on now:
    • KonaKart eCommerce Module
    • Real Wiki Module
    • User Forum Module
    • Intranet Module
    • Document Management Module
    • Data Import/Export Module
    • Server Management and Profiling tools
  • Things that can be deployed as plugins or modules to the system — not core features but extending the system to meet your needs.
  • They are adding the hooks now to make these kinds of things possible
• That is it for the roadmap folks
• 2.0 will be about 6 months after 1.9 — speed up release cycle (I’ve heard this before)

10:30:  You got and OutofMemoryException, no what?

• The session hasn’t quite started yet.  Waiting for people to return from break
• Andres Olarte and Nick Rodriguez up for the session
• Identifying the problem
  • Memory Related — could be caused by a series of events or a single event
  • Performance — Hard to identify the problem
  • Stability — Mostly caused by bugs or a combination of many different elemetns
  • Front-End -vs- Back-End
    • Front end relies on cache (in memory and on disk (1.9)) and lucene index
    • Going to the Cache can be expensive if there is not enough room in memory that is why in 1.9 is moving to allow cache overflow on disk, going to a cache on disk is much more performant than going to the DB, figuring out the permissions and all that.
    • A page is made of multiple layers — Template, Container, Contentlet, Fields — all cached separately for performance
    • Back-end always goes to database
  • Tools available
    • JMX — Standard protocol provided by Java which allows you to peek into the JVM
    • Logs — First line of troubleshooting — but they are noisy and hard to process.  (it would be nice if these were available in the UI — HINT HINT)
    • Talking to the user to identify what is actually wrong
    • Logs are good when it is one page causing the problem
    • JMX is going to be better if the server is going down after a certain amount of time and can’t be blamed on one specific page
• Creating a baseline
  • Simulate Traffic
    • Use access logs as test base
    • Organic traffic is really hard to simulate synthetically
  • Andres is showing a demo now — how to create the baseline
    • Compile a list of url from the access log of all the urls for a day or some amount of time
    • He is using siege to hit this list of urls
      • 40 users for a min
      • Ignore the first run — let the cache do it’s job
      • he got 45 transactions per seconds
      • You shouldn’t have any urls that are particularly heavy to load or simple
    • He also uses jMeter and Bad Boy
    • He is using Java Monitoring and Management Console now (jConsole)
      • Memory Usage, CPU Usage, and Threads are important here
        • When Garbage Collection runs you want it to reclaim a bunch of memory.
      • Classes are not as important
      • Gives you an online thread dump on the fly — this is very valuable
      • VM Summary gives some useful information  like uptime, startup and so forth
      • MBeans are information we can examine and change on the fly
        • Here you can actually examine what is in cache
        • velocityCache is where everything lives
        • He increased the Velocity Cache from 100 to 5000 and is rerunning the siege test … ok that wasn’t much better
        • Don’t test while the spellchecker is initializing
        • Ran again and now we are 51 trans/sec
        • Make one change at a time when testing
        • JMX will change your baseline
        • Balance between memory management and performance increase
• Understanding the system
  • Java memory management
    • Garbage Collection — it needs to run, but it shouldn’t run very often
  • Memory Utilization
    • More memory gives you better performance, this is the best way to increase performance
  • Database Usage — it is expensive no matter how beefy your DB is
  • Common Bottlenecks
    • Saving Content — if you have huge imports running in the background checking in a content can be expensive
• Memory Issues
  • JVM Memory configuration
    • If you have threads locked in completely random places it is most likely a garbage collection issue
  • Cache Config
    • Region sizes
    • Time to live — Change and make sure you watch how that affects your baseline — it may or may not help
  • Per request memory usage
  • Per session memory usage — when is the memory stored per request, per session
  • Only pull data that you need, don’t filter and sort in velocity
• Performance Issues — Nick is up now
  • per page performance
  • System-Wide performance
    • Garbage Collection — looking at this can show you if you are having an issue
    • http -vs- https — https is more expensive
  • Resource utilization
    • Database Connections
    • Client Connections
    • Enough connections to handle the requests — this is managed in the ROOT.xml  – 1 DB connection per Client connection plus a round number of buffer
• Best Practices — Andres is back up
  • Assign as much memory as is available
  • But use as little memory as possible
  • Limit the amount of data used on each page — again only pull what you need don’t filter in velocity
  • When Benchmarking, change one thing at a time to see how that affects your baseline
• Questions
  • Garbage collection management is really really hard
    • You need enough memory for GC to run effectively
    • Memory will grow at a certain point GC will run
    • When GC runs the system locks
    • If GC is happening a lot you are locked a  lot
    • This is why it is bad to increase your regions too much.
    • Identifying it –
      • Taking a thread dump: kill -3 PID
      • Use thread dump analyzer to examine it:  https://tda.dev.java.net/ — very nice
      • Look for locked up threads — locked without an explicit lock, that is probably garbage collection
  • There may be some issues with redhat linux 64 and Java 6 in re: Lucene
  • To view Cache info in jConsole:  org.dotcms > Cache Info
• End of the session folks time for lunch

12:00 Lunch

1:45  Starting the next session on Mobile Development with DotCMS  Presentation is from http://aquent.com/

• Mobile site for a device that runs a browser with HTML, Javascript, CSS
• The Challenges
  • Frequent Updates
  • Multilingual Content
  • UI Between Devices
• Staff Profiles updated Daily
• 8000+ fields
• 22 Languages — Word lengths & Different Markets
• UI differences between devices
  • Use a single webkit don’t develop different UIs for each device
• Authentication — using Google OpenID — very cool tie in for DotCMS — maps the user roles and everything
• Going further they are looking at ajax for the auth
• He wants us to try it on our phones:  http://dir.aquent.com/
• Data size — what can you cut down to make it smaller for the mobile device.
• Methods:
  • UI Design
    • HTML/CSS/JavaScript
    • Unified Design — look at wikipedia’s mobile css, it works just about everything
  • dotCMS coding method
    • DWR
      • Loads fast
      • harder to develop
      • JS Required
    • PullContent
      • Fast to develop and easy
      • Slow to load and overloads server
      • no JS required
• Now a demo of his website
  • homepage is pulling content from the dictionary
  • it’s literally only like 5 lines of code
  • Uses user agent to detect the browser
  • Don’t enable-mobile in every page just the main content they will be accessing
  • disabled form validation for phones

2:30:  The session is over now, just people asking questions — I am stoked to hear Michael Fienen’s Presentation (Who is sitting next to me) on DotCMS Best Practices next

3:00 Michael’s Session is starting soon.  I look over and he is finishing up slides as we speak.

• Maria is co-presenting with Michael
• Container Must haves
  • A Container for Includes — global variables, macro testing, Cache busting for CSS/JS
    • Set a quote variable for queries #set($quote = ‘”‘)
  • Meta Container – Page title, Meta tags, CSS, JS
  • Stats Container – For Google Analytics and others
    • Use the $host variable to determine the hostname
• Templates -vs- Container
  • Templates should only be used for layouts.  Try to use as few as possible
  • Contains are things you reuse or are editable
  • Doctype should be in the template
  • <head> should be in template, and CSS/JS that is specific to the templates
• VTL files
  • Limit use of vtl files for simple widgets
  • Save them to a central directory
  • To override a macro’s vtl files
  • Don’t abuse them
• Widgets
  • Simple Widgets — dynamic code that doesn’t need parameters – generic, dynamic tools
  • Structured Widgets — Take parameters — A front-end for macros
• URL Maps — coming in 1.9
  • ties a url for the details page to a field in your structure
  • Use a custom field for the “slug” to build the slug for you based off of your title
• Custom Forward pages
  • /cmsHomePage virtual link for your homepage
  • You can also do this with /cms###Page for 404, ect.
  • Build an automatic 404 reporter off of the vtl servlet url
• Valid HTML and 508 Compliance
  • Validate your code before you spit them out
  • TinyMCE will not do this for you, it tries, but it doesn’t
  • MS Word Hates the Interent
• Get @fienen on twitter or http://www.google.com/profiles/fienen
• dotCMS Cheat Sheet – http://tinyurl.com/dotcmscheatsheet
• DotCMS book coming out with 1.9 — hopefully
• You can customize the TinyMCE editor

Ok that’s all for today folks — watch for another post tomorrow.