Yes, I was thinking married with family. And many medical policies these days don't include things you think should be covered, like visits to a doctor's office. Most kids spend their first two years seeing the doctor constantly and the costs definitely add up.
I took a look at my recent medical needs, did some rough math on the raw costs of doctor visits, weighed that against various plans and deductibles, and pretty much went for the far end. A fair amount comes out fo pocket, but over all I'm good. And currently healthy.
I would encourage anyone you has not yet acquired (or has since shucked) too many obligations to strike out on your own while the risks and costs are still low. You may find that it isn't your cup of tea, but the longer you wait the harder it gets, and you risk kicking yourself in the ass later on in life, always wondering, "What if... ?"
Plan on spending $600-700/month. Prescription coverage is especially hard to get. (When I started consulting, insurance was $600 PER YEAR!)
That's nuts. I'm self-employed in Arizona, and pay ~$400.00 a quarter for single-person health insurance. Unless you have reason to expect frequent doctor visits and treatment, or need to cover dependants, you can do quite well with a high deductable and lower annual payments.
NEVER SIGN A FIXED PRICE CONTRACT WITHOUT A DETAILED, COMPLETED SPECIFICATION
Indeed. I learned the hard way that everyone as a different idea what "done", "complete", and "finished" mean. In the best of cases you and the client can amiably resolve differences, but you should always try to be a specific as you possibly can right up front. The goal should be to minimize surprises. The last thing anyone wants to hear is, "But when you said [...], I assumed you meant [...]."
Ruby is a programming language. Easy to learn, but very powerful, combining features from Smalltalk and Lisp (among others) but with a more friendly (i.e., C-like and file-based) syntax.
Rails is a Web-site framework built using Ruby, much as Struts is a framework/tool-kit built using Java.
Ruby makes for an outstanding first language. Learning to use Rails (or Nitro or Wee) could serve as a "next step" course for developing Web applications while examing Ruby's meta-programming facilities.
My issue with Microsoft has more to do with standards and when it does have a problem the kind of feed back it gives. I am a technician for a web hosting company, and I run into cases every day, where if Microsoft had just opted to use the standards that everyone else uses, their product would be more stable, and easier to use. For example, why is it that IE still does not read Wc3 compliant code correctly.
Go grab a copy of Zeldman's Designing with Web Standards. Flip though it and see if you can find the place where Zeldman, who should know if anyone does, says that as a point of fact, XHTML, etc. are not actual standards, they are recommendations, and that putting the word "standards" into the book title was a bit of "guerrilla marketing", since Designing with Web Recommendations just doesn't have the same zip.
Web "standards", such as they are, are more based on what the majority of people choose to use.
Why don't you look at my website and check out my CV?
OK, Mr. Smartypants, I just took a look; it's called perl or Perl, but never f'ckin' PERL.
So there.
(Seriously, though, it looks like you do cool stuff. Just not in PERL.:) )
Re:Ruby on Rails
on
DHTML Utopia
·
· Score: 2, Informative
Why not respond to this post saying how Ruby on Rails and AJAX can work together?
Ruby on Rails has clean, built-in support for template code that generates the client-side Javascript for using the prototype.js library.
It makes it next to trivial to create, for example, Google Suggest text fields because the developer focuses on using Ruby syntax to indicate the server action to invoke, based on what client behavior, and what to do when the results come back to the browser. The annoying little details that are easy to muck up are handled for you.
Did anyone else that the "ease of configuration" for building applications might be driven by the Ruby on Rails push?
WTF? No. People have griped about configuration issues before Rails, and there has been action in the Java community to address this before Rails.
Ruby on Rails does not occupy the same space as Java server app development; RoR is perhaps closer to PHP app building (though clearly lightyears ahead). People pick Java, warts and all, for various reasons, but generally because it does things other languages such as Ruby (currently) cannot (but wait for YARV!).
This may shock RoR fanboys, but many things happen in the world of software development that in fact have nothing to do with Rails.
I'm not sure you really understood how the DOM works... The initial page may still be valid, but the modified DOM won't be. Try CTRL+A + right click => View Selection Source under Firefox and validate that one. I betcha the validator will tell you to stick it up your ass.
Nothing shall be going up my ass, thanks. The XML being validated is the original text being sent to the browser.
If your client or your boss has specified that the project shall use a Strict DTD and shall work when XMLHttpRequest is not available, then you can't use AJAX.
You can use JavaScript to add elements to the DOM after the page is loaded. The page will still be valid, but the DOM available to the script will be usable for all that AJAZZ.
In the meantime, how many geek sites will finally stop linking to Amazon anytime the mention a book?
On the one hand, some number of the tech-savy get (justifiably) upset over Amazon patenting the trivial. On the other hand, Jeff Bezos is a Web 2.0 darling, and Amazon Web APIs and so Hot and Cool and Hip and Now, so many of these same geeks cannot act as if Amazon can do no wrong.
The original Amazon patent and boycott uproar clearly had *nil* effect, and I expect there to now be a deafening silence from most of those who really should know better.
Re:Sounds like it's missing something
on
Data Crunching
·
· Score: 1
I read the sample chapter online, and got the impression that the author was spreading himself too thin. While the content was more or less correct, it demonstrated a lack of real understanding, with a few clear mistakes.
Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.
You will ALWAYS have to trade off a learning curve for increased productivity.
So you have to learn things to do new stuff? Thanks for the insight.
No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run. (I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)
For many tasks one is better served learning about ActiveRecord (or Og, for that matter), on its own, and using it where needed. Or going a more agile route and using Nitro. Or opting for a different design pattern altogther and chosing Wee. There is far more in the Ruby Web world than Rails, but only one has the hype.
Of course you could just learn PHP & code everything from scratch. Then you wouldn't need to learn anything else. Of course, you get orders of magnitude less productivity.
Or, get this wacky idea: Just learn Ruby and code everything from scratch. Then you wouldn't need to learn anything else. And still get extra productivity.
There are indeed many good things in Rails, things that work best by offering a handy sublayer for common tasks without occluding the essential Rubyness of the code. But there are also things that enforce a distinctly Rails idiom, which takes you away from Ruby idioms. It's increasingly become a kitchen sink framework (e.g. what's with all the JavaScript/DHTML macros? Why couple the client to the server?)
The problem is that most incoming developers are coming from TMTOWTDI languages...
Um, isn't Ruby TMTOWTDI? Granted people gravitate towards certain idiomatic ways of doing common things, but there is certianly more than one one, etc.
Books and tutorials are necessary to beat this into the heads of incoming developers.
Hey, great sales pitch. "Buy this book so we can beat some sense into your ignorant newbie head!"
Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.
This book is highly anticipated and the distribution model (Beta now, Final later) is also unusual.
No, not really. Many authors have made prerelease versions of their books available. The main difference here is that people are required to commit $$ to the final product before it is actually ready.
This is damn good marketing. Late in releasing your product? Fearful a competitor will get to market before you and steal your thunder (and revenue)? Sell a product that isn't finished, claim this is some sort of groundbreaking, "open source" publishing technique, and get people to proofread the work they've already bought.
Re:Is RoR Part of Scientology?
on
Ajax On Rails
·
· Score: 1
Is RoR Part of Scientology?
Damn you, I spit up my coffee. L. Ron Hansson?
Yes, there appears to be a core set of Rails fanboys who never miss a chance to slag off ABR (Anything But [Ruby|Rails]). This is quite sad, as the freakish hype and nonsense coming from many of these people denigrates both the general Ruby community and the truly good things in Rails.
FWIW, I hope people do not equate Railers with the more general Ruby community, which is overwhelmingly tolerant and open to new ideas and alternative approaches.
People SHOULD develop for open standards on the web
Which would mean no GMail or Google maps, as they rely on the very non-standard XmlHttpRequest object.
Google (and others) made a choice to use non-standard Web development because they were more interested in achieving a particular experience for what they considered a reasonable number of users.
That, in the end, is what matters. Not the Official Nod from a vendor consortium.
Are there advantages to using only W3C recommendations? Sure. But failure to do so is in itself not valid complaint. Or no?
I don't want them to see my site the way they want to see it. I want them to see it the way it was meant to be seen.
You have zero assurance that will ever happen. Typically, a site servers up some markup (e.g. HTML) to some client. After that, it is the client's call on what to do with what has been sent. Given the range of possible clients (lynx to IE to firefox to some cellphone to whatever), the best hope is that at least the full text will appear in some form or another. But there is no contract, no promises of this.
You can try serving up nothing but images, but even they are open to bitmunging. Maybe you should see if the DMCA can be invoked to scare people away from freely manipulating the raw content that has been sent from the server.
Web designers/developers/authors need to get over the idea that the Web is a medium of control. It has never been true; Greasemonkey is just the latest in a series of client options for acting on raw server responses.
If you are serving up HTML, then the only "pure" rendering would be to show the actual markup; anything else is an interpretation. Once it leaves your server, it is out of your hands.
I've looked but have yet to see a BBC article that mentions the use of Lynx, or includes any statement from the accused offereing a explanation of his behavior. So far as I can tell, the "jailed for using Lynx" bit has no substance.
BTW, was there ever any verification, aside from an unsubstantiated claim from boing boing, that the mere use of Lynx was in fact what triggered the suspicion of hacking?
Slashdot Mirror
I took a look at my recent medical needs, did some rough math on the raw costs of doctor visits, weighed that against various plans and deductibles, and pretty much went for the far end. A fair amount comes out fo pocket, but over all I'm good. And currently healthy.
I would encourage anyone you has not yet acquired (or has since shucked) too many obligations to strike out on your own while the risks and costs are still low. You may find that it isn't your cup of tea, but the longer you wait the harder it gets, and you risk kicking yourself in the ass later on in life, always wondering, "What if ... ?"
That's nuts. I'm self-employed in Arizona, and pay ~$400.00 a quarter for single-person health insurance. Unless you have reason to expect frequent doctor visits and treatment, or need to cover dependants, you can do quite well with a high deductable and lower annual payments.
NEVER SIGN A FIXED PRICE CONTRACT WITHOUT A DETAILED, COMPLETED SPECIFICATION
Indeed. I learned the hard way that everyone as a different idea what "done", "complete", and "finished" mean. In the best of cases you and the client can amiably resolve differences, but you should always try to be a specific as you possibly can right up front. The goal should be to minimize surprises. The last thing anyone wants to hear is, "But when you said [...], I assumed you meant [...]."
Can you point to *anything* to back this up? An interview with Matz, or a posting to some ruby-* list?
Rails is a Web-site framework built using Ruby, much as Struts is a framework/tool-kit built using Java.
Ruby makes for an outstanding first language. Learning to use Rails (or Nitro or Wee) could serve as a "next step" course for developing Web applications while examing Ruby's meta-programming facilities.
Go grab a copy of Zeldman's Designing with Web Standards. Flip though it and see if you can find the place where Zeldman, who should know if anyone does, says that as a point of fact, XHTML, etc. are not actual standards, they are recommendations, and that putting the word "standards" into the book title was a bit of "guerrilla marketing", since Designing with Web Recommendations just doesn't have the same zip.
Web "standards", such as they are, are more based on what the majority of people choose to use.
OK, Mr. Smartypants, I just took a look; it's called perl or Perl, but never f'ckin' PERL.
So there.
(Seriously, though, it looks like you do cool stuff. Just not in PERL. :) )
Ruby on Rails has clean, built-in support for template code that generates the client-side Javascript for using the prototype.js library.
It makes it next to trivial to create, for example, Google Suggest text fields because the developer focuses on using Ruby syntax to indicate the server action to invoke, based on what client behavior, and what to do when the results come back to the browser. The annoying little details that are easy to muck up are handled for you.
This may help explain more
http://www.onlamp.com/pub/a/onlamp/2005/06/09/rail s_ajax.html
Not to be confused with The Escapist
WTF? No. People have griped about configuration issues before Rails, and there has been action in the Java community to address this before Rails.
Ruby on Rails does not occupy the same space as Java server app development; RoR is perhaps closer to PHP app building (though clearly lightyears ahead). People pick Java, warts and all, for various reasons, but generally because it does things other languages such as Ruby (currently) cannot (but wait for YARV!).
This may shock RoR fanboys, but many things happen in the world of software development that in fact have nothing to do with Rails.
Nothing shall be going up my ass, thanks. The XML being validated is the original text being sent to the browser.
You can use JavaScript to add elements to the DOM after the page is loaded. The page will still be valid, but the DOM available to the script will be usable for all that AJAZZ.
On the one hand, some number of the tech-savy get (justifiably) upset over Amazon patenting the trivial. On the other hand, Jeff Bezos is a Web 2.0 darling, and Amazon Web APIs and so Hot and Cool and Hip and Now, so many of these same geeks cannot act as if Amazon can do no wrong.
The original Amazon patent and boycott uproar clearly had *nil* effect, and I expect there to now be a deafening silence from most of those who really should know better.
I read the sample chapter online, and got the impression that the author was spreading himself too thin. While the content was more or less correct, it demonstrated a lack of real understanding, with a few clear mistakes.
Why was the window so short, and what prevents extending it?
Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.
You will ALWAYS have to trade off a learning curve for increased productivity.So you have to learn things to do new stuff? Thanks for the insight.
No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run. (I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)
For many tasks one is better served learning about ActiveRecord (or Og, for that matter), on its own, and using it where needed. Or going a more agile route and using Nitro. Or opting for a different design pattern altogther and chosing Wee. There is far more in the Ruby Web world than Rails, but only one has the hype.
Or, get this wacky idea: Just learn Ruby and code everything from scratch. Then you wouldn't need to learn anything else. And still get extra productivity.
There are indeed many good things in Rails, things that work best by offering a handy sublayer for common tasks without occluding the essential Rubyness of the code. But there are also things that enforce a distinctly Rails idiom, which takes you away from Ruby idioms. It's increasingly become a kitchen sink framework (e.g. what's with all the JavaScript/DHTML macros? Why couple the client to the server?)I hate to be cynical, but O'Reilly are planning their own Rails books this summer. Not that they would hype something they didn't believe in ...
Um, isn't Ruby TMTOWTDI? Granted people gravitate towards certain idiomatic ways of doing common things, but there is certianly more than one one, etc.
Books and tutorials are necessary to beat this into the heads of incoming developers.
Hey, great sales pitch. "Buy this book so we can beat some sense into your ignorant newbie head!"
Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.
How agile. Adapt yourself to fit the framework.
No, not really. Many authors have made prerelease versions of their books available. The main difference here is that people are required to commit $$ to the final product before it is actually ready.
This is damn good marketing. Late in releasing your product? Fearful a competitor will get to market before you and steal your thunder (and revenue)? Sell a product that isn't finished, claim this is some sort of groundbreaking, "open source" publishing technique, and get people to proofread the work they've already bought.
Damn you, I spit up my coffee. L. Ron Hansson?
Yes, there appears to be a core set of Rails fanboys who never miss a chance to slag off ABR (Anything But [Ruby|Rails]). This is quite sad, as the freakish hype and nonsense coming from many of these people denigrates both the general Ruby community and the truly good things in Rails.
FWIW, I hope people do not equate Railers with the more general Ruby community, which is overwhelmingly tolerant and open to new ideas and alternative approaches.
Which would mean no GMail or Google maps, as they rely on the very non-standard XmlHttpRequest object.
Google (and others) made a choice to use non-standard Web development because they were more interested in achieving a particular experience for what they considered a reasonable number of users.
That, in the end, is what matters. Not the Official Nod from a vendor consortium.
Are there advantages to using only W3C recommendations? Sure. But failure to do so is in itself not valid complaint. Or no?
You have zero assurance that will ever happen. Typically, a site servers up some markup (e.g. HTML) to some client. After that, it is the client's call on what to do with what has been sent. Given the range of possible clients (lynx to IE to firefox to some cellphone to whatever), the best hope is that at least the full text will appear in some form or another. But there is no contract, no promises of this.
You can try serving up nothing but images, but even they are open to bitmunging. Maybe you should see if the DMCA can be invoked to scare people away from freely manipulating the raw content that has been sent from the server.
Web designers/developers/authors need to get over the idea that the Web is a medium of control. It has never been true; Greasemonkey is just the latest in a series of client options for acting on raw server responses.
If you are serving up HTML, then the only "pure" rendering would be to show the actual markup; anything else is an interpretation. Once it leaves your server, it is out of your hands.
Welcome to the Internet.
Ruby supports UTF-8.
I've looked but have yet to see a BBC article that mentions the use of Lynx, or includes any statement from the accused offereing a explanation of his behavior. So far as I can tell, the "jailed for using Lynx" bit has no substance.
BTW, was there ever any verification, aside from an unsubstantiated claim from boing boing, that the mere use of Lynx was in fact what triggered the suspicion of hacking?