QCon 2013, my takeaways

11 Mar

Web development, you’re doing it wrong, Stefan Tilkov, InnoQ

How to tell if you are doing “web” wrong

1. Your back button doesn’t work
2. On page refresh, you get the home page
3. You need to open a second browser window with the app
4. Your content doesn’t load first
5. Can’t bookmark stuff
6. URI doesn’t represent a single meaningful concept
7. Javascript is intrusive
8. Your HTML doesn’t make sense without javascript

Point being, the web already does most of this stuff for us. Stick to how the web works and don’t fight it

How to turn startup ideas into reality by taking money from strangers

When presenting, care but don’t be evangelical
Need to sell “FUND ME”, they are investing in you, not necessarily the product
Stick to a single page, if you can’t “sell it” with that then they are not the investor for you
First impressions are everything, need to be WOW
Code faster, measure faster, learn faster
Tell stories, woven with details of success and failure
Make sure you chase them afterwards, bordering on stalking, they need to see enthusiasm
Know where you sit in the market
Get everything into 12 minutes:
1. Problem
2. Attractive market
3. Unique advantage
4. Compelling investment

The road to REST
Figure your use cases and expose them on your API
The server is in charge of providing a list of links based on the state of the resource and what services are available (simplifies the client)
Client decides columns and filtering from fixed set
RESTful clients should follow links and submit forms, if not, you are doing something wrong

You are not only a developer, simplicity…
Over production is BAD! Don’t want to be doing everything that’s right but not required. Overproduction comes from the desire to create software, TECHIES BEWARE!!!
Concentrate on delivery “how do we deliver more?”
Don’t oversimplify to the point where value is lost
Question the goal, don’t delivery software, deliver change
Have some guidelines to help harness creativity
Figure out what works for your team
Think about what will help us deliver valuable change in 5-10 years time
1. Whats the goal? What do we want to achieve
2. Who would benefit from achieving the goal?
3. What technologies?
4. Question what people think are their goals
Take responsibility for change, not software
Make it simple, not easy

Architecting for scalability
Basic Amazon web platform presentation
RDS instance, multi availability zone deployment with master slave for PassSmart when scaling

What makes a great presenter
1. Talk on a subject you are passionate about or have experience in
“knowing that you know the material”
Talk about what excites you
Seeing someone who is excited is exciting (David Attenborough)

2. Tell a story
Memory capacity is a problem + registry shortage
Stories have flow, a logical progression to assist memorisation
Hierarchy to assist comprehension and recollection

3. What are the important things about the subject?
Initially, brain dump everything, don’t exclude anything
Go back through the list and pick top 5
Find a narrative to connect them then fill out the other points with the ones thrown away initially
Keep it as simple as possible

4. Simplify your slides
Context matters but not as important as style
Content is payload, delivery system needs to be powerful and single purposed
Style should focus the message, not distract
Brevity on information, it detracts from communication
Don’t clutter the presentation with images and shit
Slides support the message, every unneeded work obscures the message
Show less on more slides

5. Explain code temporally, not spatially
Don’t explain the state of the code but the dynamic problem

6. Display/visualise the dynamic problem
Prepare code in the right way highlighting one line/segment at a time
Strip out anything that simply “unpacks” arguments

7. Deliver message fearfully
Reclassify your nervousness, you are not anxious, you are excited
Reherse your anxiety
Practice in front of an audience picture
Fear is natural, transcend it

BBC Linked Data Platform
David Rogers, Senior Technical Architect
Concept abstraction (maybe use for Exodus)
Use of triples to link common concepts or content (check out “Triplestore”)
Pages are generated dynamically from the most recent tags in the triple store, the subject and object get tagged with a “relation”
Content is tagged when it is generated
Statistical stuff is still done separately
Triplestore holds canonical data, “facts” on products
Reads need to be scaled => caching
Not big data, just well organised
GeoNames, check this out
Use of Mashery to make the data “open”, aids rate limiting and manage clients

Shit happens, building to deal with it
No notes…

Painful success
1. Always check back on reality
2. You will make mistakes
3. Software is easy, data is hard
Ultimately, they looked back having realised they weren’t actually building the right stack, only what they thought was the right stack.

Building “hypermedia” API’s with HTML
HTML makes for a great API datatype as it is accessible
HTML can be viewed in a browser and consumed by the client (a python wrapper or something similar)
Use of forms to do CRUD, a non programmatic way of constructing the data
Check out the video if possible

Startups, how to lean on others and get stuff done
Small beautiful architectures
“Don’t allow your codebase to evolve into a big ball of mud”
Make it work, make it right, make it fast – Kent Beck
Create features with a hypothesis around how they impact
Make sure the hypothesis is easily validated
Write code that is always production ready and easy to change
Lesson 1, simple user testing is simple, don’t assume anything and always be validating
Lesson 2, Use tools to discover simple mistakes, passing tests doesn’t ensure production ready, use SQL Explain on slow queries
Lesson 3, Shorten the request/response cycle, do the minimal amount of stuff possible. “perceived performance is more important that actual performance” (conditional loading etc)
Lesson 4, Focus on your differentiators, don’t over engineer stuff
Lesson 5, Simple elegant design can prevent complex architecture creep
Lesson 6, Feature flags, offer resilience as well as a way to offer features
“complex should just be lots of simple”

Wearable technology

Hire education
Message on the job advert must be inclusivity
Where are you advertising?
What are we actually hiring for?
Try and give the interviewee a good experience
Both you and the candidate must be sure, gear the conversation towards booths parties happiness
Clear thats its a 2 way conversation
Offer opportunities for feedback
Is this person smart enough?
Don’t hire yourself…
Look for evidence, experiential, hypothetical, credential, opinion

Phone screen to weed out time wasters
Pair coding in the interview???
Role play, how do people play as a group?
Challenge, make this code as good as possible, comments, logic etc
Stay for the day?
When feeding back, be constructive
Give the candidate a good run through of what the company is like and what they will be doing on a day to day basis
Ask the candidate, “what job do you want?”
Ask the candidate to explain something they have built, then ask them how they would improve it

Rich HTML5 apps
Knockout.js, look at its data-bindings and obervables usage
Windows Azure looks really nice, like the server side scripting bit

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: