Now i can easily bring my favorite aliases and commands to different environments: macbooks, linux and freebsd servers.
Ruby symbols should be just immutable strings to avoid all that mess with string/symbol keys in option hashes. Just treat every literal string as immutable one. You could even keep this nice syntax with a colon to save some keystrokes.
So, basically:
String.should < ImmutableString
“symbol”.should == :symbol
Parser still fills a table of symbol when it encounters literal strings in the source code. So the unique number is just a string object_id.
When you compare two strings, you compare ids first and if they are not the same, you proceed with byte comparison. No need to convert :symbol.to_s.
How to make string a mutable one? Just #dup or #clone it.
“symbol”.dup.class.should == String
1. “Classic”: explicit require and manual dependencies resolution.
Pros: no bugs.
Cons: lazy programmers want to write and maintain less code.
2. “Rails method” (dependencies.rb): catch const_missing in runtime, guess the file name, load it.
Pros: zero-configuration, good automatic dependencies resolution.
Cons: file name guessing is a constraint, hard to debug runtime threading issues.
3. “Merb method” (load everything in a loop, reload failed files):
Pros: zero-configuration, moderate automatic dependencies resolution, no threading issues, issues are explicit and may arise in a bootstrap process only.
Cons: twice loaded constants yield warning, hidden repeated configuration bugs may appear.
4. “io language method” (load everything sorted by filename):
Pros: no bugs, zero-configuration, easy to understand, optional manual dependencies resolution.
Cons: 2-5% of files are named with ugly prefixes like A0_message.io (higher priority) or Z_exceptions.io (lower priority).
Note: no method saves you from manual resolution of the two-way referencing issue (when A references B and B references A). You still have to create a special “header” file to put bootstrap definitions into.
Conclusion: Merb method is essentially Io method with additional “feature” (which is buggy by nature) of double loading files in case of LoadError. If you name your files according to Io method and resolve all interdependencies manually, Merb will load them once and in the correct order.
We have a small team working with SVN. I like to write code under Git. Everyone is okay with command line except Sylvaine, our designer. She uses nice update/commit menu item in the Finder for her SVN-tracked PSD files.
So, here are all the facts:
0. We are working with Mac OS X.
1. I want all revisions stored on my machine.
2. I want good branch support for the source code.
3. I don’t need sophisticated branches for PSD-like documents.
4. Sylvaine probably does not want to open terminal to type “ga maquette.psd && gc ‘new block ’ && gush”. She wants to do this from the Finder with few clicks.
5. We have awful Mac GUIs for both Git and Mercurial (none for Git and halfass MacMercurial)
6. We have git-svn which works fine.
Result: keep individual documents under SVN, enjoy GUI and use git-svn in the Terminal. For source code use Git.
Everybody might be happy.
Sadly, those who have not done 400 hours of homework just continue messing with Perl.
On the other hand, those who missed that weekend are installing Vista at XYZ Inc. IT dept.
We already know CSV and TSV: comma-separated- and tab-separated- table formats. CSV looks ugly in human-readable files, TSV suffers from the invisible whitespaces and editor-dependent formatting.
I suggest another format for human-readable files: a list of records with fields separated with two or more spaces.
This helps to format the file with spaces only and avoid bloating file with quotes (and quote escape sequences). Text looks nice and light without unnecessary commas, quotes, backslashes and invisible tabs.
The only rule is:
1. Lines are separated by [\r\n]+
2. Fields are separated by \s\s+
The parser is obvious.
Actually, this format is already used in a variety of config files in *nix systems. Most noticeable example is /etc/fstab.
PS. Never use tab character where possible!
Some web2.0 guys might not understand quite well what each part of the “ehm-veh-ceh” pattern should and should not do. They should forget about “fat model and thin controller” misconcept. Today we try to help them. (Code should be light in either case.)
First of all, a simple example about “why it matters”:
A music player contains two volume controls and a sound stream. One control is a slider, another one is a “mute” button. Sound stream has an API with “volume”, “bass”, “track number” properties. If you try to modify sound stream directy within button and slider event callbacks, you will face a problem of UI consistency: when mute button is clicked, slider should be disabled or slide down. Ad hoc attempt is to bloat your callbacks with bunch of if-then-else branches checking all the possible cases in the whole UI in each callback!
A better way is to setup a single controller for all the volume controls with two actions: “triggerMute” and “setVolume(level)”. Then, subscribe each button to a volume property of the sound model, so that slider moves a handle according to the current volume level and mute button looks “unpressed” when the level is > 0. The final step is a controller which simply sets the volume level or triggers it. The only visible if-then-else branch here is the triggerMute method which should check the current volume level before changing it. However, this is an application-specific behavior which is out of scope of MVC pattern.
Generally speaking, your application is about “entities”. Given that:
1. Models are about state of entities. They describe consistent state and referential integrity within the whole system. Model must guarantee that any transition will result into consistent state. Model defines validations and constraints, but doesn’t define how transitions are performed (e.g. doesn’t check permissions). In case of database record, it should allow to change any values in any way, but ensures the consistency of the state just before transaction is committed. Perfect Model does not have “action” methods, but reader/writer accessors only.
When you write tests for a model (you write them, don’t you?) you should not describe an “operational process” with a model, but rather check that any possible update yields a valid state or appropriate errors are raised.
2. Controllers, on the other hand, are about actions. Controller does not bother about consistency of state (it may be stateless) but it specifies the control flow. That is, checks permissions, creates, deletes and moves entities around.
In a test for a controller you should describe initial state of the system, perform an action and then check the resulting state.
3. Views are about representation of the entities. View does not modify the entity, but it accesses its data, observes changes made to a model and generates events for a controller. When you test a view, you should define a set of entities (the input) and check their representation (the output).
The most simple and powerful MVC picture looks like that:
M -> V
V -> C
C -> M
View observes the state (M.) and updates itself when state is changed.
Controller observes the view and performs appropriate actions when some controls are triggered.
Bonus track. How to write perfect tests for a music player “volume feature”?
1. Model test verifies that volume level could not be below zero or over 9000.
2. Controller test checks several values for the “setVolume” method and two cases for the “triggerMute” method: with level = 0 and level = 1. Before the test, volume level is set to some value and after the action it is checked.
3. View test should check that the slider and the button generate events for the controller and observe events generated by the model.
Goddamn, developer MUST be independent. Switch on your brain, please. RTFM.
Software source code is not a big truck a static thing. It evolves over time. Some piece of code being repeated in several places doesn’t always mean that it should be DRYed right away. There’s always such thing as coincidence. When you are putting some functionality into reusable module it should have a meaning applied to the business logic, not just “repeated lines of code”.
What’s the big problem with the “premature drying”? When compiler looks at the code, it just executes it. It doesn’t really matter how deep in the classes and functions some expression is located. It is just a matter of performance.
But when developer looks at the code, he constructs abstractions and loads them into his brain. Developer speaks abstractions language, not expressions. When I see some method/module being used in several places, I understand that as a kind of relationship existing between those places of the system. I see something in common. This idea influences further understanding and I’d better not to be wrong at some point.
Rule of thumb: don’t try to save less than 273 bytes of code if it may lead to confusion and create more abstractions or rules to be remembered.
1. Controller is not aware of our business logic and that’s a good thing.
Project.new(params[:project])
2. Initializing objects using hashes is convenient. Also, DataMapper uses it internally to initialize associations.
Project.new(:any => :param, :goes => :here)
3. Some params are special and are not allowed to be manipulated by user.
Project.new(params[:project].reject{|k,v|
k.to_s =~ /^id|owner(_id)?$/
})
4. Some params are not so special, but are accessible by specific user groups.
@project.update_attributes(params[:project].reject{|k,v|
k.to_s =~ /^owner(_id)?$/ &&
@project.owner != current_person
})
5. While models maintain consistent state of the system (key uniqueness, correct data formats and relationships), controllers maintain control flow (hence the name) along with authentication and authorization.
6. Therefore, currently used mass assignment protection implementations do not solve the problem. attr_accessible/attr_protected methods in ActiveRecord get in your way. A plugin for DataMapper I wrote yesterday also doesn’t help.
7. The right solution is a mix-in module for controllers with before filters, which should safely instantiate all necessary models.