Monday, November 15, 2010

Friday Rubyconf Notes

Keynote
DHH delivered a passionate, amusing diatribe against the development culture that demands that the programmer must be controlled. Hence the likes of strictly-typed languages, waterfall, throwing code over the wall, and all the resulting demoralization that goes along with it.

David asserted that freedom carries with it the potential to do great good as well as great evil.

I suddenly appreciate how special this Ruby community and culture is: because of our freedom, we all aspire to very high moral standards of opportunity, fair play, and nurture. Because this freedom to express yourself is a precious freedom indeed, I see many people in this community joyously giving themselves to preserve it. My church makes the same entreaties in its community, yet at this time they don't seem to come even close to this community's results.

RubyConf has been a refuge from the greater American atmosphere of distrust, cynicism, spinning, and unhappiness. Thank you all, I am very grateful.

LDAP, the Original No-SQL

My main takeaway from this talk is that LDAP has some special strengths that make it a good choice for some applications:
  • Distributed
  • Mature
  • Asynchronous
  • High-Performance
If the application has a high read-to-write ratio, the case for using LDAP as opposed to other "No-SQL" solutions is very good indeed.

Rubinius - What Have You Done for me Today?

The main goal for this Ruby variant is to leverage the Ruby language itself to implement the Ruby engine as much as possible.

Evan Phoenix has made a lot of progress since I last saw his presentation at Railsconf. Development has continued to take advantage of the "Ruby-ness": better than average benchmarking and profiling tools.

They are now working to be compatible with version 1.9.2. The future includes a Windows version and full concurrency.

MacRuby - why and how

Matt Aimonetti showed the latest version of the Ruby that can directly access the OS X objects in Cocoa. This make MacRuby a strong contender for implementing Mac applications.

To the question: when will it be available for iOS, Matt could only say that, aside from having to implement a garbage collector, there are no other technical issues. The real issue is whether Apple wants to support that capability.

Having used Smalltalk to learn the Windows API in the 1990's, I can only hope that Apple enables the same capability using MacRuby.

pie: the making of a DSL for simple games

I was tired of technical presentations and wanted to see what other Ruby efforts were going on. Here Sarah Allen testimonied about using Ruby to develop a simple DSL for an adventure game. What was interesting was her thought process and how checking out her early design ideas with others caused all of the "rewriting" to take place in the beginning when it was easy.

By taking it to children early, she gained valuable insight on what held their attention and what didn't. As expected, the childrens' ages mattered a lot.

I learned a lot about distributing early versions to the customer and how to benefit from their feedback.

Socalist Software Development

CJ Kihlbom is from Sweden and he admits he has a "socialist" point of view about developing i the Agile Ruby environment. Both amusing and insightful, he illustrated how seeing the opportunity glass "half-full" makes the Ruby community much more joyous and supportive. Among the software practices that are "socialist":
  • Open source
  • Pair programming
  • Collaboration
The results of these practices are a large number of benefits:

* Flow
* Lessons distractions
* Camaraderie
* Helps w/ morale
* Work w/ people you like
* Better morale
* Stability
* Immunity from a developer hit by a bus ("bus number")
* Learning
* Apprenticeship
* Formal apprenticeship programs
* "Apprenticeship Patterns Guidance for the Aspiring Software Craftsman" O Reilly
* Mentoring
* Find someone we can inspire
* The teacher benefits as well as the student. Building the community strengthens us.
* Competition
* We're competing for the same talent and sometimes project. But really we're collaborating.
* See life as more than half full.
* Craftsman swap - competing consulting companies swapped developers for a week. They learned a lot from each other. This has been catching on.
* Obie: we are competing against consulting shops outside our community.
* Solidarity - So we can all grow and all improve.

One question was raised: how can we influence other software communities. For example, how could be influence a badly-run Java shop?

CJ makes me want to move to Sweden. ;-)

Automated Acceptance Testing, The Vietnam of Test Driven Development

Paul Wilson discussed how being unclear about the role and intent of different test strategies can get your development efforts bogged down in a never-ending slog of developing tests that don't really do you any good.

He focused on acceptance testing, which I realized I had confused w/ end-to-end testing, system testing or integration testing. They are not the same.

Acceptance specifications are a tool to flesh out unclear business requirements, and acceptance tests verify that the acceptance specifications are implemented. Hence, the acceptance test is built for the stake-holder and the terminology should reflect his vocabulary. Phrasing it in UI terms is unnecessary unless the UI is part of the acceptance specification itself; many times it's business rules. Hence test wherever the acceptance criteria are specified.

Matz's Keynote

I didn't take notes on Matz's presentation; rather I just listened. He talked about some upcoming features in Ruby 2.0: mainly features to reduce risk in monkey patching.

He also talked about "Rite" (Ruby Light) for embedded systems.

Saturday, November 13, 2010

Thursday Rubyconf Notes

w00t! My first Rubyconf! My testimony of this great event. Today: Rubyconf's first day:

Opening Keynote by Dave Thomas

I didn't take notes on this; just listened. Dave went thru the history of his involvement w/ Ruby, the books and how it grew beyond his wildest expectations.

His last part touched me the most: find someone and mentor them into the Ruby community. His comments would have more meaning to me as the conference unfolded.

Debugging Ruby Systems by Aman Gupta

Aman described all the "heavy hitting" tools to use when the problem lies outside of using console or irb to figure out what's going on:
  • lsof
  • strace - linux only - trace system calls and signals
  • tcpdump - dump traffic on a network - use wireshark for decomposing results
  • perftools - google's performance tools
  • cpuprofiler
  • perftools.rb (available on github)
  • rack-perftools - rack middleware for prftools.rb
  • ltrace - trace library calls. Is presently unable to trace into shared libraries; ltrace/libdl will fix this.
  • gdb - the GNU debugger
What I would find out later is the attempt to integrate what these tools do in one application. But these were good; sometimes I've used one or another but it was helpful to have the entire selection explained again.

The Polite Programmer's Guide to Ruby Etiquette
by Jim Weirich, Chris Nelson, and Ed Sumerfield

Basically, how to not break others' code when you use 'method_missing' and similar powerful Ruby features.
  1. When using method_missing, delegate what you don't handle to super.
  2. Beware there are several "hook" methods:
    1. method_missing
    2. constant_missing
    3. etc
  3. When using method_missing, don't forget to handle responds_to as well.
  4. When publishing a gem, don't forget to put that gem's dependencies in the gem description file. There is now a feature in the description file to also specify additional gems depended upon only during development.
MetricFu, a code analysis tool
A static checking toolset.

There are quite a few independent software packages covering different metrics:
  • Flog reports. Measures complexity. Also top 5% complex ones.
  • RCov. code coverage. What lines in your code has been executed by tests.
  • Reek: bad naming
  • Play: copy-paste detection. Is fairly good at
  • Saikuro - cyclosomatic complexity. Covers branching complexity
  • Source - Source Control Churn.
  • Roodi: Tries to find definite code design.
That's quite a few different outputs to wade through. MetricFu organizes all output in one graph per method. Hence, MetricFu is based upon Caliper and accomplishes the "unification" of static metric output on a per method basis.

ZOMG - Why Is This Code So Slow?
Aaron Patterson put on a performance that will be a classic video to watch in coming years. In a very humorous way, he explored a Rails 3 anomaly that we experienced ourselves, a mysterious and significant ActiveRecord performance slowdown.

In telling it like a detective story, Aaron walks us through his motivations and thinking in
  1. Discovering the problem
  2. Deciding that it's worth his time to fix it.
  3. Understanding the problem
  4. Fixing the problem
Of course it was not that straightforward. Aaron realizes that understanding the problem will probably take MUCH more time than he wants to invest, so he goes through all the "standard optimization" stuff and gets some benefit. But, the fundamental problem remains the same: the speed slows down as the square of the number of terms in the query.

Finally, he breaks down and decides to work to understand the problem.

He spends 3 weeks (or was it 6) in just this exercise. An extensive part of his education comes from automated benchmarking; don't leave home without one. Once Aaron truly understands the code, he realizes some design that will have to be changed. I.e. a rewrite. So he does. At the end, all of the lost time is recovered and then some.

Along the way I "relearned" some computer engineering fundamentals and had was thoroughly entertained as well: Benchmarking. Diagrams that describe how the code is organized.

My takeaway is that Aaron reminded me that tough problems require a plan of action that almost always requires an extensive time period to study and understand the code causing the problem. This can be hard to choose when you're in a tough constrained time box. I have to continually "check my footing" before I jump to conclusions about the cause of a problem and attempt a solution before I really understand the problem.

Oh, and checkout graphviz.org for a great free diagramming tool.

It's Time for a Ruby Editor

This talk introduces RedCar, a recent Ruby-implemented editor. Why?
  • Integration - Syntax analysis is easier
  • Convenient - Can extend easier
  • Fun - Not as much a language curve
  • Power - API not limited by
A demo showed examples of the above.

Takeaway: very interesting. I'm still fantasizing about pairing RedCar with Rubinious as the foundation of a truly impressive Ruby IDE. ;-)

Maintaining Balance While Reducing Duplication

David Chelimsky cited chapter-and-verse about the evils of duplication code. That being said, he showed how to remove duplication thoughtfully, that is, without breaking it or making it hard to read.

The guiding principal is that removing duplication should improve code clarity, not obscure it. It therefore helps to remember that DRY calls for the removal of duplicated functionality, not just the minimization of keystrokes. This is so that functionality can be changed in once place.

Another way to look at it is that every piece of knowledge should have a signle unambiguous authoritative representation. Always consider purpose and intention.

Improving DRY means adding levels of indirection. Always make sure that the code depends on other code that is not likely to change.

Suggestions for Making your "DRY-improvements" better:
  1. Depend on things that are less likely to change.
  2. The problem is not that you have to change code in two places. The real problem is that you don't know you need to change it in two places.
  3. Duplication is not always obvious. This is especially pernicious in rspec.
  4. Duplication often results from "feature envy".
Knocking Ruby's Date and DateTime Performance Out of the Park with home_run

Jeremy Evans discusses how the real problem with Date and DateTime performance os the powerful but slow date parsing for date strings. You can improve this if you limit the parsing options.

Friday, February 26, 2010

OCRuby Feb 26, 2000 meeting minutes

Thought I'd post this here since the OCRuby group submission is moderated.

This is mainly interesting for the Mongo DB presentation by Tommy Chheng.

Attendees:

Dash
Tina
Michael Hartl
Tommy Chheng
Scott Smith

Michael has published 7 chapters of his electronic book at railstutorial.org

Tommy: Whither Mongo DB for Natural Development

Used by:
  • github
  • EA
  • The New York Times
  • sourceforge
  • The Business Insider
The above are "big" sites.

Why?
  • NoSQL trend?
  • Scalability?
  • Natural Development!
Compare

SQL fixed schema
  • Data model Rows/Tables
  • Data Types Primitives
MongoDB Dynamic
  • BSON Documents/Collections
  • Primitives+Arrays/Hashes
Records vs Documents

SQL
3 tables
  • Documents
  • Revisions
  • Tags
MongoDB
  • document = {title:...} (reads as Javascript code)
  • BSON data structure naturally maps to most programming languages hash object.
  • ORM can just be a thin layer.
  • Can debug Mongo a lot easier.
Mongo Install

How to use in Ruby?

Easy to use in Rails or Sinatra
2 gems
  • mongo+mongo_ext gem
  • mongo_mapper gem


MongoMapper Models
  • No Migrations!
  • AR Validations
  • AR Callbacks
  • Testing using Facory Girl
  • Rails 3?
    • fork which uses ActiveModel, see mailinglist
    • is complete but not merged in yet.

MongoMapper Model

(sample code)

CouchDB or MongoDB?

CouchDB
  • One big database
  • HTTP REST
  • Find by id ma/reduce JS functions
  • MVCC
MongoDB
  • Many collections
  • sockets
  • Find by id - dynamic JS queries
  • Update in place
MVCC - updates by making new version copy; good for data safety.
Update in place is a lot faster

MongoDB by default writes to disk in batches

Limitations

Memory Mapped file:
  • 32-bit 4GB limit, use 64-bit
Atomic updates only at document level
  • Solve by nesting related data in document
MongoDB lacks:
  • transactions
  • CouchDB-style MVCC revisioning

Author

Twitter @tommychheng
  • using mongoDB + mongo_mapper!

Thursday, February 25, 2010

Scenes from LA Ruby Conference - 2010 - Announcements

Take Away

Continues to be lots of interest and activity in Ruby. Conferences in San Francisco and Phoenix announced for this year. Jobs are available, especially in San Francisco.

Job Available

Product Manager - Slingshot Labs, incubator for News Corporation
Looking for a senior Rails developer.

Ruby Conference

Josh Susser and Jim Myer
Golden Gate Ruby Conference
Announce Fall conference - Sept 10,11 2010 (fri/sat)

Primary Sponsor for Today's Conference

ATT Interactive
Buzz.com - social website. Have t-shirts. NOthing to do w/ Google

Ruby Conference

Derek w/ Sunnyconf in Phoenix
Sept 25.

LA Ruby Monthly Meetings

Alf Mcgollough 2nd Thursday of each month.
Meetup.com/laruby.
Looking for west side venue that can handle 50 people.

Job Available

AT&T interactive hiring
  • Ruby and data skills
  • Ruby and web and UI skills
  • Oracle/Ruby
  • Service type work in Ruby/Rails
Job Available

NextspRocket.com
Place to pay money to fix open source bugs.
Check out the site.

Ron Evans - thanks to organizers

Scenes from LA Ruby Conference - 2010 - Large Databases

Take Away

Large databases are very sensitive to mistakes that don't affect smaller databases. Anything that causes scanning of many records will not only run slowly, it frequently causes the entire web site to go down. Prevent scanning by careful application of indexes and avoiding data transformation operations when querying.

Introduction

Tim Morgan - scribd
  • We learn rails when we break it
  • scribd is a really large web site (Amazon S3)
  • Large sites are easy to break.
Infamous mistakes

These are the ones you remember for a long time (along w/ everyone else).

Causes
  • Almost always problems of scale.
  • Almost always about how Rails interfaces w/ database.
  • Postgres/Oracle, but MySql is what is being used.
  • If you add something that is a SQL request, look at the SQL itself.
  • Always understand the queries your code is generating. Look at the query log.
  • Test with a heavily populated database. If you find it sucks, think what your customers think.
  • Pay close attention to your indexes.
  • MySql and Postgres have very different implementations of bow their indexes work.
The problem with find_in_batches.
  • Doing it using User.all.each is going to be very slow.
  • Better to use find_each; uses batch for x items per request.
Composite primary keys? Use composite keys plugin.
http://gist.github.com/105318 is a monkey-patch

validates_uniqueness_of
  • :case_sensitive => false
  • took site down.
  • problem was SQL lower(login_name)
  • In mysql, make the case-insensitive column binary.
  • solution http://gist.github.com/105367
problem with delete and destroy
  • caused by misleading Rails documentation
  • delete_all is faster than destroy because it doesn't use hooks.
  • before_destroy positioning is important, must be placed before any associations.
  • delete_all() doesn't remove the link table record itself; it just sets the id column to nil.
  • Solution: use delete_all
  • CategoryMembership.delete_all :category_id => self.id
  • Fixed in Rails 3.0
problem with indexes

Think about indexes early.
  • mysql uses only one index at a time, so you may have to figure out an index on multiple columns.
  • you may have to tell MySql which index to use:
  • use index (index_documents_on_user_id).
Conclusions
  • Always understand the queries your code is generating.
  • Test with a heavily populated database.
  • Pay close attention to your indexes.




Scenes from LA Ruby Conference - 2010 - Data Structures

Take Away

Fascinating talk on using probabilistic data structures to save oodles of search time if a limited number of false indicators can be tolerated.

Introduction

Tyler McMullen - Scribd

Different Data Structures

Why?
  • Speed
  • Memory
  • Clarity
Some very interesting structures
  • Bloom Filter
  • BK-tree
  • Splay Tree
  • Trie
Bloom Filters
  • Tests for existence in a set
  • Probabilistic
  • Minimal memory use
Example: 100million strings in a set
Tradition set: 10gb minimum vs 280mb

How does it work?
Binary sequence. Uses hash
In places where occasional false positives are okay

BK-tree

find items within a distance of a target
reduces search space
works inside a metric space

Triangle Inequality
If we know the distace between 2 of 3 points, then we can make assumptions about the distance between the remaining "unmeasured" two points.

Uses:
  • Most often used for spelling corrections
  • Work in any metric space
  • Reduce the search space.
Splay Tree
  • Self-blancing binary tree
  • Brings most accessed items toward root
  • The more uneven the access pattern, the better the performance.
Good for caches, garbage collectors, etc.

Trie

(pronounced "try")
  • O(1) (order 1) on lookup, add, removal
  • Ordered traversals
  • Prefix matchine
  • Excellent memory management.

Useful as an autocompleter.

Interesting, he implemented this as a rack filter.

Scenes from LA Ruby Conference - 2010 -Teaching Ruby to Kids

Take Away

It's great to see Sarah evangelizing software training to kids. I've thought about it for a long time and her presentation will spur me to do it. Very good hints on how to do it so that both you and your students both thoroughly enjoy it and become better practitioners.

Introduction

Sarah Mei - Teaching Ruby to Kids

Teaching is her hobby.

Why?

Most programming instructors = FAIL
Teacher needs to be a coder.
Programming is becoming part of basic literacy.
Why should you teach?
  • Rewarding
  • Teaching leads to learning by the teacher.
  • Teaching not rocket science.
Agile teaching
  • set goals
  • form a plan but expect to adapt
  • keep iterations short
Set goals
  • specific
  • imediate,
  • measurable
Form a plan
  • What do I start with?
  • Keep your goals in mind.
  • Software Teaching Tools:
    • Shoes
    • Hackety Hack
    • Small Ruby
Theme
  • Kids love anything visual
  • Anything interactive
  • irb: compelling for kids (maybe)
Plan
  • Install all the tools you might use on all the computers the kids have access to.
  • start small
  • Use the internet.
Short iterations
  • Your "lesson plan" should be a series of very small steps.
  • 15 minutes or less
Listen to the customer
  • Follow tangents!
  • don't stick to a plan because it's the plan.
  • Don't worry about "finishing"
  • Look for teachable moments.
  • Look for signs they've turned off

"Ruby: the programming language for extroverts"

Deploy continuously
  • Do it often, practice
  • Teaching is a learned skill.
  • Take all opportunities you can to teach.
  • talks at your local meetup
  • pair programming
  • summer camps, etc, need volunteers
  • National Lab Day
  • In SF, I always need teachers for intro workshops.
Expect some things you try to fall flat.
  • Some students won't engage
  • Keep at it.

Summary:
  • You should teach
  • You can teach
  • Agile is form more than just development.
  • Practice.
Ruby is a great first language.

For really young kids:
  • Scratch
  • Kodu (Microsoft)
  • ISTE has curriculum for elementary school.
  • cs-unplugged (a web site)

web-kit and javascript.

These are drag-and-drop environments.

Scenes from LA Ruby Conference - 2010 - Web App Performance Monitoring

Take Away

Bjorn showed New Relic in action with how it monitors web sites and identifies issues early and clearly. Unfortunately my blog entry here fails to capture much of it as it was mostly demo. Worth looking into.

Introduction

Bjorn Freeman-Benson - New Relic

Building the First Successful Human-Powered Airplane

Paul MacCready
1977 - gossamer condor

Why did Paul succeed?

How to make the lightest possible airplane as quickly as possible? Ended up crashing a lot.

Could repair in less than 12 hours. Others crash repairs 6 months.

Macready team could iterate faster.

Applied to Software Development

Presenter wants to be that agile.

How he uses the New Relic to do that.

larubyconf
https://rpm.neweelic.com
30 days of RPM Gold for free.

Monday, February 22, 2010

Scenes from LA Ruby Conference - 2010 -Civic Hacking

Take Away

Luigi showed how government has lots of useful data but few tools to make sense of the data. Here's where software developers can make a contribution: to build free tools to make this data more accessible. He talked about the various opportunities and why accomplishing them would make a real difference.

Introduction

Luigi Montanez
luigi@sunlightfoundation.com
@LuigiMontanez

Purpose: get government to open up its data and provide software tools to comprehend it.

Over a thousand people in their effort.

16-paid staff.

"D.C. is Hollywood for ugly people."

Guiding principles:
  • Electoral Politics no
  • Governance yes
  • Open source
Civic Side Projects

Purposes/Challenges
  • Challenging entrenched bureacracies
  • Open source + Open data = better Government
  • Government opens data; they write apps aeround it.
  • Government as a wholesaler, not retailer.
Sunlight Labs API
  • Bio and contact info for elective office holders.
OpenSecrets.org
  • Contributions
    • Example: how much health insurance money has been spent politically and how.
GovTrack.us - Bills and Vote Records

MAPLight.org - Vote Influence
  • How representative voted correlated w/ donations.
Code for America
  • Will choose 5 cities
  • 5 developers will be supplied to each of those cities.
  • Modeled after Teach for America program.
Getting Involved.
  • groups.google.com/group/sunlightlabs
  • #transparency on Freenode
  • github didn't get actual repository
Benefits:
  • Enhance your skillset
  • Low risk, high reward
  • Another testing framework? Really?
  • Local/state govts. an untapped market
  • Solve a hard problem.
TED Talk
  • David Cameron: in a Ted talk "The next age of government"



Scenes from LA Ruby Conference - 2010 - Garbage Collection and the Ruby Heap

Take Away

The traditional Ruby engine is paranoid about memory management because it has to run in so many disparate environments. This negatively impacts the garbage collection performance. If you know or can define where your Ruby installation will run, you can do optimizations that will greatly speed this process. Indeed, this is one of the benefits of Ruby Enterprise, and Ruby 1.9 accomplishes a subset of the optimizations discussed here.

Note: this session went extremely fast and I was not able to collect the notes as I wanted.

Introduction

Joe Damato and Aman Gupta
@joedamato @tmm1

Garbage Collection and the Ruby Heap
  • Why GC
  • Ruby is simple and elegant
  • GC makes life easier.
  • No more memory management
    • Menory management
    • memory leaks
MRI
  • Always allocated on heap
  • Fixed size
  • sizeof(struct RVALUE) = 40

See their site to see how to optimize the GC.

Ruby memory leaks:
  • These are reference leaks
memprof - replacement for gdb.rb and bleak_house

Scenes from LA Ruby Conference - 2010 - Threads and Processes

Take Away

Good discussion of the different facilities available to Ruby and the underlying operating system and their tradeoffs.

Introduction

Aman Gupta - Joe Damato - Threads

http://timetobleed.com Joe's blog.

Fundamentals

What is a thread?

A thread is just a set of execution state.

Models
  • Green threads
  • Native
  • Hybrid
Green 1:N
  • Lightweight
  • Kernel doesn't know they exist
  • Implementation is in userland.
Pros
  • Create lots cheaply
  • Switch them.
  • Schedule them however you want.
Cons
  • Main one is that these can switch only between a single Ruby process.
Native Threads 1:1
  • Kernel knows they exist
  • Some user land code.
Pros
  • Take advantage of SMP
    • Shared memory
    • Blocking in one thread doesn't block
Cons
  • didn't get
Hybrid Threads (M;N)

Pros
  • Take advantage of SMP
  • Cheap setup and teardown
Cons
  • Need 2 schedulers
Ruby 1.9 and Erlang use hybrid threads

Preemptive Multitasking
  • Operating system switches process regardless of process states.
Cooperative Multitasking
  • thread gives up voluntarily.
Fibers

Tools
  • strace
  • google-perf
lsof - "list of open files" - a utility. Can also be used to get a list of open sockets.

strace

trace system calls and signals.

Ruby: SIGVTALRM used

github.com/ice799/matzruby
  • heap_stcks branch
  • heap_stacks_186 branch
github.com/tmm1/ruby187
  • fibers branch

Scenes from LA Ruby Conference - 2010 - The Next 10 Years

Take Away

A warning that the rate of change in underlying software development paradigms will require new mental approaches to the large software challenges lying ahead of us. The "algol-based" languages used by the vast majority of developers will yield to more scalable functional languages.

In the meantime, continue to grow you skills and constantly learn how to take advantage of tools to get more bang for the time you spend designing and coding.
Introduction

A new look at software development - What will the next 10 years bring?

Dave Astels
Twitter: @dastels
dastels@engineyard.com

Observations:
  • You're doing it completely wrong.
  • Software is hard
  • Software construction is the most complex endeavor ever undertaken by mankind.
  • The only software that's worth making is software that does something new.
  • It's only getting (more)...
    • more complex
    • bigger
    • distributed
    • parallel
    • life critical
30 years of software

think about...
  • popular languages
  • flavors, blends, derivatives
  • Fortran->Algol 54/58
  • Lisp 58
  • Ruby described as new-age lisp.
  • Smalltalk from lisp from simula
Some outliers
  • Prolog --> Erlang
  • ML --> Haskel
Time for a change?

Let the computer do more work.
Declarative Languages
  • What you want to do instead of how.
Functional Languages
strong type systems
  • language agda
Tools that cooperate
  • real-time analysis of our codes.
Do more for the developer
  • Giving some insight into the code you're writing.
  • Static analysis
Generated test suites
  • Identify boundary cases.
Runtime analysis

Will current ideas continue to server us?

Speaker says NO!

evolution/revolution

new way of programming

We need parallel strategies
  • problem decomposition
  • data structure design
    • distributed
  • algorithmic organization
We need:
  • better languages
  • better tools
    • tools that help us.
Google's "Go" language
  • everything is parallelized.
parallel and distributed baked in
  • that actively prevent bugs
closing quotes: (Guy Steele):
  • The bag of programming tricks that has served us for 50 years is the wrong way to think going forward and must be thrown out.
  • The great tricks of sequential programming don't work.
Summary
  • It's a parallel world of parallel problems.
  • Have strategies that assume imperfection. How do we write code that way?

Scenes from LA Ruby Conference - 2010 - Mobile Ruby

Take Away

Programming for mobile devices is a lot more than adjusting to the smaller screen; there are additional opportunities in the mobile devices themselves: GPS, camera, motion sensors, etc. However, they have significant challenges: comparatively primitive development environments, and operating systems. These are discussed along with how HTML 5 and Rhomobile are working towards a single programming API across mobile platforms.

Introduction

This was presented by Sarah Allen of Blazing Cloud (gotta retrieve the presenter's name)
Rhomobile framework call "Rhodes"

Mobile app development sucks:
  • Awkward
  • In some ways is archaic
    • Old languages
Brand Transcends Platform

My brand instead of cell phone brand. (Do I agree w/ this?).

Mobile gives you more than desktop:
  • Geolocation
  • Camera
  • Connected
  • Everyone you know is connected
Means you have different opportunities than desktop.

write Once - Run Anywhere

How to get code onto the device.
  • Rhodes is similar to Rails.
  • Views are HTML.
  • It all works within the device. So a kind of HTML processor is inside the device.
It's also analogous to Rails:
  • Controller -> RhoController
  • Model -> Rhom
  • View -> eRB files
Javascript alternatives:
  • Titanium

Scenes from LA Ruby Conference - 2010 - The Big Rewrite

Take Away

The primary danger in the major rewrite is proceeding before the business has bought into it; this is usually fatal (or you end up wishing it was fatal). Along with the important technical skills needed, this talk identifies how to know when the business is behind it, and how to help to navigate the business to support the rewrite. (Or, to determine that it's not a good idea to do the rewrite at this time.)

The Big Rewrite, Doing it Right

Rich Kilmer

btw, he used a presentment software package called Prezi which was very effective with swirling text while zooming.

Drivers for a Rewrite

  • Must be business driven
  • Must NOT be technology driven
  • Don't call it a rewrite
  • Complete in a major release cycle
Why? Costs money and resources. Business has to see value.

Preparing for a rewrite

Drop a major release before you start.
  • One the customer is really happy with.
  • Understand your domain
  • Or have a domain expert available all the time.
  • Break down the current system into logical sets of functionality. (Rich later showed the resulting code which was incredibly clean; this made a (hopefully) lasting impression on me.)
  • Choose the right technology for what you want to do. Examples:

    • Develop a standard worker framework (minion, resque)
    • Dedicate resources to repeatable data migration
    • Keep services code consistent, models clean
    • Use the right tool for each job

Flip It

  • Perform incremental migrations of historic data
  • Prepare business users for potential disruptions
  • Run flip scenarios several times
  • Enable "read only" system during final lip (if needed)
  • Provide a way to fall back if the flip fails

Miscellaneous

  • Don't code for assumptions.
  • If you find that you want to use the same name for two different classes, you may have two different domains which might need different applications.
  • Design for expectation that backing up separate systems will probably not backup synchronously. So be prepared to recover disparities.