Good use for old newspapers
I wonder how this works with magazines. I have a huge stack of old magazines. Might need some tape to make larger strips to weave it with.
creating delicious apps for a better world
Web Addresses to Include Chinese and Arabic Characters
by Caleb Johnson — Oct 26th 2009 at 2:00PM
Despite what some might say, it's not often that an opportunity comes along to change the lives of billions of people. But that's just what the Internet Corporation for Assigned Names and Numbers (ICANN) will do by changing the rules of Web addresses, shaking up the Internet like never before. According to the Daily Mail, the ICANN board will pass a resolution this Friday that will allow entire Web addresses to be written in non-Latin alphabets. Those languages could be anything from Japanese to Arabic, or Hindi to Greek. The change means that many people around the world could more easily navigate the Web, and even create Web sites in their native tongue. Of the 1.6 billion people who use the Internet, about half are native speakers of languages that do not use the Latin alphabet. "This is the biggest change technically to the Internet since it was invented 40 years ago," said ICANN chairman Peter Dengate Thrush at a press conference in Seoul, South Korea yesterday. If approved, the first non-Roman domain names should hit the Web sometime in mid-2010.
But why now? For years, the group has been testing a new translation system to convert multiple scripts into a single address, and it finally feels ready to put the system to use. We don't want to count our chickens before they hatch, but this is big news, folks. It's akin to the introduction of a three-point line in basketball, or the forward pass in football. This resolution will totally change the game, so you might want to brush up your Arabic or Chinese. [From: Daily Mail and DownloadSquad]
via switched.com
Uggh. Is this going to cause problems or what? If you want to email someone on an email server with a non-Latin domain name, would you need to somehow type in those funky non-Latin characters? Talk about Babel all over again (Genesis 11:1-9)!
Comments [1]
Thoughts on the Aloha on Rails Conference (Part 2 of 2)
For part 1, go to: Thoughts on the Aloha on Rails conference (Part 1 of 2)
Here's Part 2 of my thoughts on the Aloha on Rails technical conference that I attended earlier this month. (Oct 5-6) I want to write down what I personally got out of the conference before I forget it. I meant to do this sooner, but I've been busy applying some of what I've learned. This post covers the sessions I attended on Day 2 of the conference.
Jim Weirich's session: Grand Unified Theory of Software Design
- Jim introduced a term called connascense, which for software design purposes means the way two pieces of code are coupled, or two things that have to change together when one of them changes, in order to preserve correctness. There are different degrees of connascence:
- Connascence of Name (CoN): where two components use the same name to couple, such as passing named parameters within a hash, or using the name of a method or variable to refer to the same thing.
- Connascence of Position (CoP): where the order matters, such as the order of parameters in a method call, or where positions in arrays are hardcoded. The coupling can be made more robust by converting this down to CoN.
- Connascence of Meaning (CoM): using values to mean something for the two components. (Like "404" error code means page not found). These can be assigned to constants to somewhat reduce to CoN, but even in the assignment of values to constants, there needs to be contranascence (where two components have to be different, in order to preserve correctness) between the values to that the same value isn't assigned to different constants that are supposed to be different.
- Connascence of Algorithm (CoA): the two components depend on the same algorithm to work right. For example if there is a method that creates a checksum (add_check_digit) and a check method to verify that a checksum matches. Can DRY (don't repeat yourself) it out by having a separate method that does the algorithm, and having both these methods call that method. (CoA->CoN)
- Rule of Software Locality - Within the same module, there is stronger connascence. When it is farther away, use weaker forms of connascence.
- Rule of Degree - convert higher degrees of connascence into weaker forms.
- Thoughts: I can see how this makes software easier to understand and more maintainable - certainly for Ruby On Rails, this seems to be the way it is evolving. I'm not sure this applies as well to lower level languages though, or when optimizing for performance. Say you want to write a highly optimized device driver, or you want the data to be as small as possible (sending an array in json using CoP and CoM, as opposed to sending a json hash), you might want to use a stronger form of connascence.
- There were several more forms of connascence he talked about, that seem to be a bit different than the previous ones:
- Connascence of Timing: using mutual exclusion in race condition
- Connascence of Execution: Depends on the order of execution
- Connascence of Identity: getting two separate objects to represent the same logical object (two pointers to the same object)
- Connascence of Values: constraints on the values: in graphics, left < right, top < bottom
- Connascence is only part of the grand unified theory of software design. There are other parts: cohesion and comprehensibility (human factor).
Chad Pytel and Tammer Saleh's session: You're Doing It Wrong
- When refactoring (when working on a legacy code rescue project) talk with your client to see if they actually still need the feature
- In rescues where there are no existing automated tests, write integration tests for existing behavior, and unit tests for new features
- Webrat & Selenium are key for doing these tests
- Add functional tests for new controllers, one at a time
- Rake tests can be tested too by moving their methods into a model. Make the rake task skinny.
- Rails views are composed of many parts (html, css, js, ruby). Know your rails helpers and how they change across rails releases.
- Use the yield/content_for helpers to do page titles (the <title> tag in the head) for better MVC separation
Charles Nutter's session: JRuby From Zero to Awesome
This talk/demo was amazing! Charles gave several demos of JRuby projects that just blew me away on how easy it was to use java functionality from ruby, calling methods in a very ruby-friendly way. If I have to build new stuff on top of legacy java code, then I'll definitely consider using JRuby to do it.
Blake Mizerany's session: Forget Kindergarten, Learn to Scale
Some tips on scaling, based on cloud computing with heroku
- Don't keep state on the local environment. Everything must be disposable.
- Share nothing. The server is not for persistent storage of dynamic assets. (temp uploaded files)
- Be impatient: Keep everything under 200 ms. Use caching if it is needed. Rack::Cache and Memcached
- Procrastinate: If it takes over 200 ms, run a background job.
- Be unfair: handle monsters separately
Anthony Eden's session: Technical Debt - Rewrite or Refactor
- technical debt is inevitable, so plan for it, or pay it back with interest or time
- TATFT!
- minimize code so you can pay back technical debt quickly
- pair programming disseminates knowledge
- Set aside (schedule) time to deal with technical debt
- Tasks:
- get rid of cruft (commented code)
- remove methods that are no longer invoked
- write tests for untested code,
- use the client to see if any more code can be thrown away
- refactor existing monster code into smaller pieces, DRY it up
- Candidates for rewrite:
- if there are no existing tests, you're very likely going to need a rewrite
- low quality code
- owner of code is no longer there
Corey Donohoe's session: Everything I Know About Being an Open Source Hacker I Learned From Indie Hip Hop
I learned much more about the Hip Hop community than about the Rails community from this talk. Key takeaway points for me:
- Meet other developers, perhaps at a local meetup, or attend 2 conferences a year
- Check out other developers' code on github, and post your own.
Panel discussion: Modeling Maturity
- railsmaturitymodel.com
- There are very different views on this. Some very strong opposing views against having a Rails Maturity Model (reminds of all the bad things of CMM)
- Related question: How does the client know who is legit and uses best practices, and who is a charlatan?
- Check ruby-toolbox.com for good new plugins
Benjamin Sandofsky's session: Staying Above the Ghetto
- RoR is a luxury brand: affected by the economy, and frequently copied
- Our values as a rails community: aesthetics, pragmatic, freedom, passion
- Our bane: commodity developers - the kind who write corporate training sites, cheap, and don't care
- Learn, create, share
__________
For me personally, I've got some todo's based on what I learned:
- Get a github account
- Play with JRuby
- Take a look at the plugins from Gregg Pollack's talk
Filed under //
Aloha On Rails
Ruby on Rails
Comments [0]
The Dyson Air Multiplier: A $300 Bladeless Cooling Machine (TreeHugger)
via treehugger.com
I wonder how much air it moves per second compared to a normal fan of that size, and the noise level. They should make a giant ceiling fan version of it.
Comments [0]
How Rewards Can Backfire and Reduce Motivation (from Psyblog)
via spring.org.uk
"tangible rewards tend to have a substantially negative effect on intrinsic motivation (...) Even when tangible rewards are offered as indicators of good performance, they typically decrease intrinsic motivation for interesting activities."
Comments [0]
Must See - sand animation
via flixxy.com
This young Ukranian girl tells an entire story by pushing around sand on a table. She uses nothing but sand and her hands to create these images.
Comments [0]
Thoughts on the Aloha on Rails conference (Part 1 of 2)
I had a great time at the Aloha On Rails conference (Oct 5 and 6), getting to meet other Ruby on Rails developers and listening to the speakers. It was great being able to see the people behind some of the blogs I read, or gems/plugins that I use. I really really hope that this becomes an annual event.
Here are the top pieces of takeaway value that I personally got out of the conference from Day 1 (for a description of each session, see Aloha On Rails Sessions). I'll write more on Day 2's sessions in another post.
From Chad Fowler's keynote: Passionate Programmer:
- A lot of developers hate having to do marketing. (like me) But marketing is a moral imperative. If you believe that you have a great product or that you have a great service to offer that will be of value to others, then you're cheating others if you don't tell them about it.
- What are you spending your passion on? As passion drains away, execution drains away.
- The problem with inspiration is that it is not consistent. You need to systematize it. Calling software development an "art" is just an excuse to not systematize it.
- The framework for succeeding in the software industry is: choose market, invest, execute, market, systematize
- Something that I thought was odd was that Chad said that he wouldn't do programming if he didn't get paid for it. I love to program, and my favorite projects have been the ones I don't get paid for. And there's all the developers who truly enjoy doing open source. Chad does say to practice though (Code Kata and Ruby Quiz), but I guess he means it with the goal of practicing so that you getting paid more later on.
From Blythe Dunham's session: Hey is that your database crying?
One group of tips I was reminded of is: While Rails does a good job of doing validations, it is useful and safer to also put some of those validations in the database as well, such as having "not null" columns, using unique keys, and default values right in the migrations.
From Greg Pollack's session: On the Edge of Rails Performance
I pretty much got my full registration cost back from the value of this talk. Greg went over 9 awesome plugins/libraries for rails performance and optimization. They are listed here:
From Marty Haught's session: Lean Teams - How To Do More With Less"
Essentially just stay focused on adding nothing but value, learning from the users, maximize flow/minimize effort, and ship features when ready. Also he introduced me to the "kanban" system which is an agile methodology which seems to increase the flow of value by limiting the number of works in progress. Here's the link for kanban: Limited WIP Society - Home of Kanban for Software Development
Desi McAdam's session: Dragons, Riddles, and Rails Applications
One practice I haven't heard much of but makes a lot of sense is: "Keep explaining to the client what you were doing for the client." This is especially useful when the work doesn't involve changes that are apparent/visible to the client, such as rescuing/refactoring nightmare legacy code so that it can be more maintainable or enhanced.
Pat Maddox's session: Domain Driven Rails
- A good metric of code quality is WTF's per minute when someone is reading through the code.
- Check out the resource_controller plugin
- Sometimes ActiveRecord callbacks (after_create) can make it harder to follow the code.
- Sometimes moving things from the controller to the model might may testing slow/hard and code hard to follow (ex: an after_create activation/verification email delivery for a User model), in which case a service class would be more appropriate. Look at alternatives to callbacks: service classes, command objects, event handlers
- Stuff that goes in the <title> tag should really use a yield and content_for, rather than being set in the controller or model, since this really is part of the view.
Yehuda Katz's session: Rails 3 Public API
In Rails 3, some of the big long methods are being broken down into smaller parts, which means it can be more easily customizable. We'll be able to get stripped down "metal" versions of many of some of the fat bloated classes and choose which modules/mixins to put in.
Michael Nieling and atthew McVicar's session: You Don't Need A Logo
- Details matter, be consistent, design is never done
- Design and details differentiated Starbucks, iPod, and Flickr from their competitors who had similar producs. They had the best design and looked at all the details of the entire experience.
- Design stewardship - everyone needs to be involved in complying with the design. Have a Design Usage Guide. An design needs to be at almost every point of the process.
- When using a design agency, get them to explain/justify every design decision, and provide you with documentation. Have to be able to justify how it is delivering actual value, rather than just based on "taste".
- Most people can't tell the difference between good and #1 (Chad vs Kelly Slater when surfing), but can tell between a beginner vs good.
- Get the client to tell the "what" and the "why". We'll figure out the "how".
Panel session: Is Agile Too Slow?
- Identify your sacred cows and question them (always write tests for everything? etc)
- Sometimes putting together cucumber scenarios helps out to flesh out requirements. They let you know when you are done.
- Selenium - lets you test the UI
- When is hacking (going without tests) OK? "If you're not getting paid for it", or "at the start" if you don't know if the project/prototype will go forward
Filed under //
Aloha On Rails
Ruby On Rails
Comments [0]
Comments [1]