I've been using Rails and Ruby for the past few months -- I had no prior experience with either.
The thing that has become clear to me is that the hard part of Rails is learning *how to do it right*
The "automatic code generation" (scaffolding) is helpful for learning *how to do it right* but as you get deeper into the framework, you find yourself coming up against difficult and/or domain specific problems. In all cases I've encountered so far, there are simple solutions to these problems -- the hard part was finding the right way to solve the problem.
You have to take the time to read the documentation, dig through the source code, think about design patterns, and write elegant Ruby code.
Often, this code is only a few lines long. For example, I had an issue with SQL statements including NULL values when I wanted to pick up a default from the table schema. The solution was a single line of code to remove the named attribute from an array in a Model subclass. It took a few hours of research & prototyping to figure out that one line of code.
So as far as maintainability is concerned, I'd say it's pretty good. That one line of code mentioned above is easy to understand for someone doing maintenance. Less is more.
One final observation that I've made regarding Rails and Ruby -- it's a lot like Cocoa and Objective-C (another excellent framework backed by a dynamic language.) When you find yourself writing a lot of code, it's a good sign that you are doing things wrong.
"As a precautionary measure, Sony BMG is temporarily suspending the manufacture of CDs containing XCP technology," it said in a statement.
So why aren't they recalling the product that's already in the channel? There are thousands (millions?) of discs sitting on retailers shelves that are just waiting to install the rootkit. Oh yeah, that would hurt their bottom line.
Until it costs them, they're not going to learn.
-ch
So who's going to be the first?
on
Video Tombstones
·
· Score: 1
So who's going to be the first to hack one of these to show goatse?
I think the most important feature of this new mouse is that it works like a single button mouse in the default configuration.
Last month, my wife was on the phone with her mother providing tech support. I'm not exaggerating when I say that she said "NOT THE RIGHT BUTTON, MOM!" about 20 times. The context menu was coming up, and the selected action (default) was not the one needed.
Her mom is not stupid, but she does hit the wrong button on her mouse. To her, there's no difference -- they both click.
The Mighty Mouse will work fine for people who just want the simple click-n-go interface. Also, since the default configuration is to not have a right button, it forces developers to "keep it simple, stupid".
Power users (e.g. your average Slashdot reader) can benefit from multiple buttons -- and go to the preference panel to enable the additional functionality. Some intermediate level users may even learn about the "power of the right click" by seeing & exploring the preference panel -- good for them, too!
This is what I like about Apple -- creating solutions that work for a wide range of users.
How a context menu works is NOT completely understood.
The other night, my wife was on the phone with her mother providing tech support. I'm not exaggerating when I say that she said "NOT THE RIGHT BUTTON, MOM!" about 20 times. The context menu was coming up, and the selected action (default) was not the one needed.
Her mom is not stupid, but she does hit the wrong button on her mouse. To her, there's no difference -- they both click.
And keyboard combinations are not a valid comparison -- you don't accidentally click on the keyboard and the mouse at the same time.
Having a one button mouse makes sense for people like her. Power users who can (and do) benefit from multiple buttons can go out and buy a better mouse.
Using ARD to access an Intel dev machine means that anyone with access privileges can observe/control an active session. The active session may not be something you want another person to see (e.g. it could be a session from another user on the machine editing their source code in Xcode.)
In order to rent out test time, you'd spend a lot of time/hassle managing observe/control permissions in the Sharing preferences panel.
That said, it's going to be very beneficial to us and our geographically dispersed development team.
Providing developers with a toolkit to port their apps to the Mac is nice, but I don't think it will have much impact on the Mac software ecosystem.
Take a look how Java applications have been accepted by the Mac masses -- not very well. (Server side, it's a different story, of course.)
The problem is that these Java apps don't feel like a Mac app. menu bars are in the wrong place, keyboard shortcuts are wrong or missing, control layouts are poorly aligned, fonts that are hard to read, etc.
To make a good Mac app, it takes more than a recompile against a new toolkit. In many cases, it requires a total re-think of the UI.
Still, I'm glad to hear about this development. It will make apps that have a marginal market available to Mac users. There are apps that are available on Windows that I'd like to have on the Mac -- and I don't care if the UI sucks.
WINE will run on a Mac. This is *HUGE*. Imagine running any Windows software, at native speeds, with OpenGL support, on Mac OS X.
This can't be emphasized enough. This is REALLY HUGE.
In the next couple of years, you'll see PLENTY of open source emulators that will let you run your Windows app on OS X. But you'll NEVER see something that allows you to run your OS X app on a Wintel PC (see Phil Shiller's comments here)
Bottom line: you don't NEED the Microsoft OS -- you NEED the Apple OS.
The problem is not Xcode -- the problem is Metrowerks.
Metrowerks support for the Mac has been slowly declining in the past few years. With Apple having a free development environment available, you can hardly blame them.
The issue is that there are a lot of legacy codebases that use Codewarrior. Having Adobe and Microsoft management on stage saying "we're moving to Intel" means "we're moving from Codewarrior to Xcode".
And you can bet that won't be easy. But, it's obviously necessary.
For smaller developers, who don't have the resources of an Adobe or Microsoft, going from Codewarrior to Xcode won't be easy. And in some cases (eg. plug-in developers) it's not even clear if it's possible -- depends on when/how SDKs and other ancillary development stuff get updated.
So, in summary, I'm not worried about our Xcode projects -- but I'm still in the "WTF?" stage for the ones that use Codewarrior.
I find that 99% of the questions I have can be answered by these two resources (especially newbie type questions -- which you're bound to have in a new development environment.)
Icon Composer is fine for developers who "just want to get the job done". If you're a designer who's developing a suite of icons with a consistent theme/style, you're going to be using Freehand/Illustrator and Photoshop (easier to review & edit.) To output from Photoshop, they use IconBuilder
When you're dealing with applications that have hundreds of icons (think about MS Office) tools like Icon Composer just don't cut it.
It's only a matter of time before we see a.TXT virus. Sounds implausible, but virus writers are very good at adapting to people's work habits.
Many companies block.ZIP at the perimeter (at a firewall or mail server.) People still have work to do -- so they workaround this block by renaming.ZIP files as.TXT files. We have several clients who *REQUIRE* us to send them files us like this.
So, once people get into the.TXT ->.ZIP -> unarchive habit, they'll be happy to do the same with a virus.
And it's going to be fun seeing the whole IT infrastructure that relies on file extensions fall into a crumbling heap.
Many websites include a favicon.ico file in the root directory of the site. This icon is used in favorites to display the site's logo, etc.
Now, without knowing too much about this vulnerability, it seems possible (likely?) that any Windows app that displays icons would be at risk since the rendering of icons is handled by the OS.
In theory, Firefox would be as much at risk as IE -- both display favorite icons. And neither has a way to block the display of these icons.
(The CAN notice is "under review", so I can't be much more specific than that.)
They're going to end up selling a lot of add-ons to something that "only" costs $499. The funny thing is that some of these things (displays, for example) actually cost more than the original device.
Now I'm wondering if you can shave 0.25" off of the thing and mount it in a 1U rack. The specs seem good for a cheap & simple web server.
Also, I predict that there will be some kind of add-on in the next 6 months that allows you to control this Mac with a infra-red remote -- something to run the CD & DVD without a display attached.
The after-market is going to have a field day with this device!
Slashdot Mirror
Jonathan Ive is doing for computers what Raymond Loewy did for transportation.
His influence, like Loewy's, will be felt for a long time to come.
-ch
I've been using Rails and Ruby for the past few months -- I had no prior experience with either.
The thing that has become clear to me is that the hard part of Rails is learning *how to do it right*
The "automatic code generation" (scaffolding) is helpful for learning *how to do it right* but as you get deeper into the framework, you find yourself coming up against difficult and/or domain specific problems. In all cases I've encountered so far, there are simple solutions to these problems -- the hard part was finding the right way to solve the problem.
You have to take the time to read the documentation, dig through the source code, think about design patterns, and write elegant Ruby code.
Often, this code is only a few lines long. For example, I had an issue with SQL statements including NULL values when I wanted to pick up a default from the table schema. The solution was a single line of code to remove the named attribute from an array in a Model subclass. It took a few hours of research & prototyping to figure out that one line of code.
So as far as maintainability is concerned, I'd say it's pretty good. That one line of code mentioned above is easy to understand for someone doing maintenance. Less is more.
One final observation that I've made regarding Rails and Ruby -- it's a lot like Cocoa and Objective-C (another excellent framework backed by a dynamic language.) When you find yourself writing a lot of code, it's a good sign that you are doing things wrong.
-ch
"As a precautionary measure, Sony BMG is temporarily suspending the manufacture of CDs containing XCP technology," it said in a statement.
So why aren't they recalling the product that's already in the channel? There are thousands (millions?) of discs sitting on retailers shelves that are just waiting to install the rootkit. Oh yeah, that would hurt their bottom line.
Until it costs them, they're not going to learn.
-ch
So who's going to be the first to hack one of these to show goatse?
Talk about being afraid to visit the cemetery!
-ch
I think the most important feature of this new mouse is that it works like a single button mouse in the default configuration.
Last month, my wife was on the phone with her mother providing tech support. I'm not exaggerating when I say that she said "NOT THE RIGHT BUTTON, MOM!" about 20 times. The context menu was coming up, and the selected action (default) was not the one needed.
Her mom is not stupid, but she does hit the wrong button on her mouse. To her, there's no difference -- they both click.
The Mighty Mouse will work fine for people who just want the simple click-n-go interface. Also, since the default configuration is to not have a right button, it forces developers to "keep it simple, stupid".
Power users (e.g. your average Slashdot reader) can benefit from multiple buttons -- and go to the preference panel to enable the additional functionality. Some intermediate level users may even learn about the "power of the right click" by seeing & exploring the preference panel -- good for them, too!
This is what I like about Apple -- creating solutions that work for a wide range of users.
-ch
Wrong.
How a context menu works is NOT completely understood.
The other night, my wife was on the phone with her mother providing tech support. I'm not exaggerating when I say that she said "NOT THE RIGHT BUTTON, MOM!" about 20 times. The context menu was coming up, and the selected action (default) was not the one needed.
Her mom is not stupid, but she does hit the wrong button on her mouse. To her, there's no difference -- they both click.
And keyboard combinations are not a valid comparison -- you don't accidentally click on the keyboard and the mouse at the same time.
Having a one button mouse makes sense for people like her. Power users who can (and do) benefit from multiple buttons can go out and buy a better mouse.
-ch
Using ARD to access an Intel dev machine means that anyone with access privileges can observe/control an active session. The active session may not be something you want another person to see (e.g. it could be a session from another user on the machine editing their source code in Xcode.)
In order to rent out test time, you'd spend a lot of time/hassle managing observe/control permissions in the Sharing preferences panel.
That said, it's going to be very beneficial to us and our geographically dispersed development team.
-ch
Providing developers with a toolkit to port their apps to the Mac is nice, but I don't think it will have much impact on the Mac software ecosystem.
Take a look how Java applications have been accepted by the Mac masses -- not very well. (Server side, it's a different story, of course.)
The problem is that these Java apps don't feel like a Mac app. menu bars are in the wrong place, keyboard shortcuts are wrong or missing, control layouts are poorly aligned, fonts that are hard to read, etc.
To make a good Mac app, it takes more than a recompile against a new toolkit. In many cases, it requires a total re-think of the UI.
Still, I'm glad to hear about this development. It will make apps that have a marginal market available to Mac users. There are apps that are available on Windows that I'd like to have on the Mac -- and I don't care if the UI sucks.
-ch
Available here.
-ch
WINE will run on a Mac. This is *HUGE*. Imagine running any Windows software, at native speeds, with OpenGL support, on Mac OS X.
This can't be emphasized enough. This is REALLY HUGE.
In the next couple of years, you'll see PLENTY of open source emulators that will let you run your Windows app on OS X. But you'll NEVER see something that allows you to run your OS X app on a Wintel PC (see Phil Shiller's comments here)
Bottom line: you don't NEED the Microsoft OS -- you NEED the Apple OS.
-ch
The problem is not Xcode -- the problem is Metrowerks.
Metrowerks support for the Mac has been slowly declining in the past few years. With Apple having a free development environment available, you can hardly blame them.
The issue is that there are a lot of legacy codebases that use Codewarrior. Having Adobe and Microsoft management on stage saying "we're moving to Intel" means "we're moving from Codewarrior to Xcode".
And you can bet that won't be easy. But, it's obviously necessary.
For smaller developers, who don't have the resources of an Adobe or Microsoft, going from Codewarrior to Xcode won't be easy. And in some cases (eg. plug-in developers) it's not even clear if it's possible -- depends on when/how SDKs and other ancillary development stuff get updated.
So, in summary, I'm not worried about our Xcode projects -- but I'm still in the "WTF?" stage for the ones that use Codewarrior.
-ch
Just tried to go order the Intel development kit and got this error while trying to login to ADC:
:-)
"The requested application was not found on this server"
Heh -- seems like I'm not the only one interested in this machine
-ch
Set your location (I used my ZIP code.) Then do a search with just "movie:" -- it shows what's playing in my local area.
Cool.
-ch
There's a simple reason for this -- after the release is declared final, and the GM disk image is created, there is still testing going on.
During the time that the GM disk is being pressed and shipped, the people in the QA department are finding bugs and engineers are fixing them.
Apple then distributes the fixes with Software Update after ADC members have time to test the seed (giving them a week or two to do it.)
-ch
Visit these sites:
CocoaBuilder for the Mac OS X and Cocoa developer list archives.
CocoaDev is a Cocoa developer Wiki.
I find that 99% of the questions I have can be answered by these two resources (especially newbie type questions -- which you're bound to have in a new development environment.)
-ch
You're in a business unit of a Fortune 100 company. You have accountants that can answer this question.
Every business is different -- ask a professional what is best for your business. That's what you pay them for...
-ch
Icon Composer is fine for developers who "just want to get the job done". If you're a designer who's developing a suite of icons with a consistent theme/style, you're going to be using Freehand/Illustrator and Photoshop (easier to review & edit.) To output from Photoshop, they use IconBuilder
When you're dealing with applications that have hundreds of icons (think about MS Office) tools like Icon Composer just don't cut it.
-ch
Thank God everyone can spell her last name correctly.
-ch
It's only a matter of time before we see a .TXT virus. Sounds implausible, but virus writers are very good at adapting to people's work habits.
.ZIP at the perimeter (at a firewall or mail server.) People still have work to do -- so they workaround this block by renaming .ZIP files as .TXT files. We have several clients who *REQUIRE* us to send them files us like this.
.TXT -> .ZIP -> unarchive habit, they'll be happy to do the same with a virus.
Many companies block
So, once people get into the
And it's going to be fun seeing the whole IT infrastructure that relies on file extensions fall into a crumbling heap.
-ch
I bet they'll be calling this model the PowerBook G5 mini
-ch
Many websites include a favicon.ico file in the root directory of the site. This icon is used in favorites to display the site's logo, etc.
Now, without knowing too much about this vulnerability, it seems possible (likely?) that any Windows app that displays icons would be at risk since the rendering of icons is handled by the OS.
In theory, Firefox would be as much at risk as IE -- both display favorite icons. And neither has a way to block the display of these icons.
(The CAN notice is "under review", so I can't be much more specific than that.)
-ch
Yeah, a small touchscreen or even a plasma display like on the Roku. That's what I'm talking about -- turn this sucker into a media center...
-ch
Apple has learned something with the iPod -- you can make a shitload of money selling accessories.
And they're focusing on it with one of the iMac mini pages
They're going to end up selling a lot of add-ons to something that "only" costs $499. The funny thing is that some of these things (displays, for example) actually cost more than the original device.
-ch
So it's true...
Wow!
Now I'm wondering if you can shave 0.25" off of the thing and mount it in a 1U rack. The specs seem good for a cheap & simple web server.
Also, I predict that there will be some kind of add-on in the next 6 months that allows you to control this Mac with a infra-red remote -- something to run the CD & DVD without a display attached.
The after-market is going to have a field day with this device!
-ch
Easy answer -- get a laptop with wireless networking. When you leave your workshop, you take the computer with you.
No wires or other hassles for setup, either.
-ch