The document is a presentation about designing code for beauty, simplicity, and usability. It discusses reasons for designing code like for one's own sanity and future growth. It covers topics like balance, clarity, and harmony in code. Balance involves alignment, order, and grid usage. Clarity involves consistent naming, positive grammar, and method extraction. Harmony involves integrating code with its applications and user experience. The presentation emphasizes writing simply and designing the user experience before writing code.
Erector is a Ruby gem that implements the “builder” pattern for HTML generation. It can save developers time by encouraging more advanced reuse in views via composition and inheritance, terse syntax, auto-closing tags and default HTML-escaping of all output. It can serve as an alternate view technology in Rails.
Using Erector makes it easier to refactor complex views by using standard refactoring techniques such as extracting methods. In ERB you can only accomplish this by helpers or partials, each of which lives in separate files. Since every Erector widget is a class, you can factor out duplication more easily than you can with helpers or partials.
Because views are just Ruby classes, Erector allows for inherited (nested) layouts by default. As a security measure, all output is HTML-escaped by default and all HTML elements are closed automatically.
This talk was given by Jeff Dean at RailsConf 2009. http://en.oreilly.com/rails2009/public/schedule/detail/8587
C(ollab) RITE: How to run impactful iterative studies in a fast paced environ...Jhilmil Jain
This talk describes C-RITE , a method that maximizes impact through cross-disciplinary collaboration on research observation, analysis, and design exploration within an agile, user-centered development framework. We showcase real-world tested techniques that Google’s Android and TV teams have developed and share tactics for reducing logistical overhead in a lean, iterative user-centered design process.
Applying Classroom Techniques to an Online CourseAimee deChambeau
This brief presentation examines a few techniques that are traditionally geared for face-to-face classes, but that I have used with varying degrees of success in my online course.
"SCRUM allows us to create better products, more suited to the users' needs. ...Anna Zarudzka
General approach and widely available knowledge make us think that Scrum allows us to create better products. We can make better ones than while using Waterfall approach. It's hard to argue with that.
The question is: Does the iterativeness itself guarantee products that are better for the users?
Is a good Scrum team, presence of the Product Owner and more intense contact with stakeholders enough to form a theoretically better path for the product?
Do we remember about Product Vision? Do we emphasise it enough?
Product Vision is not something additional, it’s not only one high-level sentence of one person. It’s the package of crucial knowledge and THE TOOL OF COMMUNICATION: Target User, Values, Competitors and more.
From a Product Vision to a running software... and back again, and agile coac...Andrea Tomasini
Eliciting Requirements and breaking them down into actionable tasks is a challenge that requires both creativity and a systematic and analytical approach. Applying agility to Requirement Engineering, means much more than focusing on full bandwidth communication instead of documentation... Discovering a more empirical approach to Requirement Engineering - an approach that allows you to focus systematically on what needs to be done, as well as allowing creative tension to emerge and find the simplest and more concrete solutions for your Requirements engineering
Erector is a Ruby gem that implements the “builder” pattern for HTML generation. It can save developers time by encouraging more advanced reuse in views via composition and inheritance, terse syntax, auto-closing tags and default HTML-escaping of all output. It can serve as an alternate view technology in Rails.
Using Erector makes it easier to refactor complex views by using standard refactoring techniques such as extracting methods. In ERB you can only accomplish this by helpers or partials, each of which lives in separate files. Since every Erector widget is a class, you can factor out duplication more easily than you can with helpers or partials.
Because views are just Ruby classes, Erector allows for inherited (nested) layouts by default. As a security measure, all output is HTML-escaped by default and all HTML elements are closed automatically.
This talk was given by Jeff Dean at RailsConf 2009. http://en.oreilly.com/rails2009/public/schedule/detail/8587
C(ollab) RITE: How to run impactful iterative studies in a fast paced environ...Jhilmil Jain
This talk describes C-RITE , a method that maximizes impact through cross-disciplinary collaboration on research observation, analysis, and design exploration within an agile, user-centered development framework. We showcase real-world tested techniques that Google’s Android and TV teams have developed and share tactics for reducing logistical overhead in a lean, iterative user-centered design process.
Applying Classroom Techniques to an Online CourseAimee deChambeau
This brief presentation examines a few techniques that are traditionally geared for face-to-face classes, but that I have used with varying degrees of success in my online course.
"SCRUM allows us to create better products, more suited to the users' needs. ...Anna Zarudzka
General approach and widely available knowledge make us think that Scrum allows us to create better products. We can make better ones than while using Waterfall approach. It's hard to argue with that.
The question is: Does the iterativeness itself guarantee products that are better for the users?
Is a good Scrum team, presence of the Product Owner and more intense contact with stakeholders enough to form a theoretically better path for the product?
Do we remember about Product Vision? Do we emphasise it enough?
Product Vision is not something additional, it’s not only one high-level sentence of one person. It’s the package of crucial knowledge and THE TOOL OF COMMUNICATION: Target User, Values, Competitors and more.
From a Product Vision to a running software... and back again, and agile coac...Andrea Tomasini
Eliciting Requirements and breaking them down into actionable tasks is a challenge that requires both creativity and a systematic and analytical approach. Applying agility to Requirement Engineering, means much more than focusing on full bandwidth communication instead of documentation... Discovering a more empirical approach to Requirement Engineering - an approach that allows you to focus systematically on what needs to be done, as well as allowing creative tension to emerge and find the simplest and more concrete solutions for your Requirements engineering
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
I never wrote it; everybody else did! How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die? How many times have you heard someone say that what really needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of ourselves and our predecessors? Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy? We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.
https://www.youtube.com/watch?v=qRP45l5UugE
How to improve your code quality? The answer is continuous refactoring. Learn more about refactoring. Know the most frequent code smells (antipatterns), telling when to refactor. Go through the catalog of well-known refactorings, telling how to improve your code.
Free The Enterprise With Ruby & Master Your Own DomainKen Collins
On the heals of Luis Lavena's RailsConf talk "Infiltrating Ruby Onto The Enterprise Death Star Using Guerilla Tactics" comes a local and frank talk about the current state of Open Source Software (OSS) participation from Windows developers. Learn what OSS is, what motivates its contributors, and how OSS can make you a stronger developer. Be prepared to fall in love with writing software again!
We will start off with a 101 introduction to both the Ruby programming language and the Ruby on Rails web application framework. You will learn about ActiveRecord, a powerful ORM that maps rich objects to your databases, and the latest components to use it with SQL Server. As a Rails core contributor and author of the SQL Server stack, I will give you a modern insight into both that will allow you to leverage your legacy data with Ruby.
Lastly, I will review the bleeding edge tools being actively created for Windows developers to ease the transition to Ruby, Rails and OSS from a POSIX driven world. Many things have changed. It is time to learn and perform some occupational maintenance.
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
I never wrote it; everybody else did! How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die? How many times have you heard someone say that what really needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of ourselves and our predecessors? Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy? We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.
https://www.youtube.com/watch?v=qRP45l5UugE
How to improve your code quality? The answer is continuous refactoring. Learn more about refactoring. Know the most frequent code smells (antipatterns), telling when to refactor. Go through the catalog of well-known refactorings, telling how to improve your code.
Free The Enterprise With Ruby & Master Your Own DomainKen Collins
On the heals of Luis Lavena's RailsConf talk "Infiltrating Ruby Onto The Enterprise Death Star Using Guerilla Tactics" comes a local and frank talk about the current state of Open Source Software (OSS) participation from Windows developers. Learn what OSS is, what motivates its contributors, and how OSS can make you a stronger developer. Be prepared to fall in love with writing software again!
We will start off with a 101 introduction to both the Ruby programming language and the Ruby on Rails web application framework. You will learn about ActiveRecord, a powerful ORM that maps rich objects to your databases, and the latest components to use it with SQL Server. As a Rails core contributor and author of the SQL Server stack, I will give you a modern insight into both that will allow you to leverage your legacy data with Ruby.
Lastly, I will review the bleeding edge tools being actively created for Windows developers to ease the transition to Ruby, Rails and OSS from a POSIX driven world. Many things have changed. It is time to learn and perform some occupational maintenance.
22. class Post
key :title, String
end
class Category
key :name, String
end
class Theme
key :moniker, String
end
23. class Post
key :title, String
end
class Category
key :title, String
end
class Theme
key :title, String
end
24. class Site
key :authorizations, Array
def add_authorization(user)
# do stuff
end
end
class Account
key :memberships, Array
def add_membership(user)
# do stuff
end
end
25. class Site
key :authorizations, Array
def add_user(user)
# do stuff
end
end
class Account
key :memberships, Array
def add_user(user)
# do stuff
end
end
27. class User
include MongoMapper::Document
key :name, String
key :email, String
key :inactive, Boolean, :default => false
end
28. class User
include MongoMapper::Document
key :name, String
key :email, String
key :inactive, Boolean, :default => false
def active?
!inactive?
end
end
29. class User
include MongoMapper::Document
key :name, String
key :email, String
key :inactive, Boolean, :default => false
def active?
!inactive?
end
def activate!
self.inactive = false
end
end
30. class User
include MongoMapper::Document
key :name, String
key :email, String
key :active, Boolean, :default => true
end
31. class User
include MongoMapper::Document
key :name, String
key :email, String
key :active, Boolean, :default => true
def inactive?
!active?
end
end
32. class User
include MongoMapper::Document
key :name, String
key :email, String
key :active, Boolean, :default => true
def inactive?
!active?
end
def activate!
self.active = true
end
end