Vinyl is an interesting one.... the DJs...just want the good user interface, because this is a musical instrument to them.
This reminded me of the real reason I'm not using a digital camera: the user interface.
Perhaps if I learned to work with a really good auto-focus system I'd like it, but at the moment I prefer manual focus with a focus scale and depth-of-field indicators. (I use scale focus surprisingly often, and not just for setting the hyperfocal distance.) Many modern digital (and even many 35mm) cameras lack the focus scale, DOF indication, and comfortable controls of the older (non-auto-focus) 35mm cameras.
And I've yet to see anything with the fantastic metering interface of an Olympus OM-3 or OM-4. That's the only camera I've ever found where I can shoot practically as fast in full manual mode as I can in auto-exposure mode. (I can spot-meter three or four points, adjust shutter speed and aperture and take the shot within a few seconds, usually.) I don't have to give up the control I get with manual mode and multiple spot-meter readings in order to get speed.
If I could get that in digital, then I'd start being tempated to switch.
Unlike film cameras, digital cameras won't last any better than the computers do, at least not for many years. The basic difference is that with my 45-year-old Olympus Pen-D2, I can take advantage of all the improvements in film technology over the last 45 years, whereas with a digital camera I'm stuck. But I don't think we really care about this; who's going to complain at getting twice the camera for half the price only three or four years after buying your previous camera?
Lenses last, but become less convenient. My Olympus OM-series 100mm F2 I will put up against any lens in the world, it's that good (and I'm not the only one who's said this). But there's no auto-focus, and it would be technically tricky even to get shutter-priority AE out of it. On a modern camera, it's basically reduced to a completely manual lens. (Well, that's how it is anyway, but at least on my OM-4 I don't have to manually stop it down while metering and shooting!)
Black-and-white film negatives, if properly processed and stored, are good for perhaps a couple of hundred hears, maybe longer. We're not quite sure yet. But proper processing is a reasonable amount of work, and it is continuing work to store them properly.
Image files also take continuing work to store for long periods. (As others have pointed out, you can't just expect to slap them on a CD-ROM or tape , come back in a hundred years, and be able to read them.) But I think it's less work than storing film negatives. You could put them on a few geographically separated servers that can communicate with each other, and perhaps some off-line backups as well. It's certainly safer than keeping one's fridges running, as you're resistant to power failures, you've got multiple copies in case of disasters, all the usual stuff. If we find digital files easier to store than paper, we'd certainly find them easier to store than film.
Format conversions are a big problem with digital files. JPEG will probably be readable forever, but who wants to use JPEG? You really want to use the raw image format from the camera, or something that holds equivalant information, but camera manufacturers are pretty set these days on using proprietary formats that change and age rapidly. (Some camera manufacturers' latest software even now can't read their earliest raw files!) If we could get everyone to buy into Adobe's RAW/digital negative format the way they've bought into JPEG, that would help. At the least, for the moment, we can convert our camera raw files to that format and store both, with a JPEG copy for backup as well.
It looks to me as if, if you use proper planning, digital will be easier and cheaper to store in the long run, and will have a greater chance of surviving disasters. But, just as with film archival storage techniques, though to a lesser degree there will be on-going maintenance costs.
On the other hand, if you toss your negatives into a drawer and forget about them, they will probably be readable longer than a CD to which you do the same. But that's heavily dependent on environmental conditions: you're basically just trusting to luck, anyway.
You mean the way a lot of musicians still insist on using vacuum tube amps? Or the way entire genres of music have sprung up around the act of mixing vinyl records on turntables? Sounds about right, actually.
Yes, exactly that. It took longer for digital audio to be able to deal with things like tube amps because their behavior is a lot more complex. But it's there now; pros are abandoning real tube (and even non-tube) amps for amp/speaker simulators left and right because the quality is "good enough" for most of them, and it's so much cheaper. ($800 for a tube amp, $200 for a mic, and $200 a pop for the studio setup time when you can just plug in a $200 simulator? Not a hard choice for most musicians.)
Vinyl is an interesting one. It's not that any of the DJs care whether it's analogue or digital (unlike some audio purists, who have justified complaints about some limited aspects of CD versus vinyl recording). In fact, I think the DJs would prefer digital, so that they didn't have these ridiculous issues like losing bass on an album as compared to the single because the tracks have to be closer together. (That was the main reason 12" singles were created in the first place: to try to compensate for physical issues in tracks with a lot of bass.)
Anyway, the DJs don't care about analogue versus digital; they just want the good user interface, because this is a musical instrument to them. I've only dabbled in DJing myself, but I can tell you that a Technics SLP-1200 certainly does feel a lot nicer to use than a cheap turntable, and both are nicer and more comfortable than a pro DVD player, when it comes to cuing and so on.
Perhaps the eventual solution there, as we move to audio transferred by telcom rather than physical means, will be the special records you can play on the turntables, whose output goes into a digital box, that then simulates digitally the playback of an audio file as if it were on the record. And then DJs can stop hauling large and heavy boxes of vinyl around with them, as well, instead just downloading from their home collection.
What digital camera can compete with with 25 ASA film loaded into a 10x8 large format camera?
It depends on how you're trying to compete. If it's making a shot without a tripod, many relatively cheap digital cameras will beat the 10x8 for overall quality. If it's resolution, well, check out The Gigapixel Project.
Digital is pretty darn good these days, and is competing reasonably well in the 35mm world. Within five years it will likely be the better choice for all small and medium format users except those who specifically like to use chemical processes for that sake alone, or due to computer-aversion. As a photographer who does all of his own processing and printing, I may not like this, but I still don't see how black and white is going to do any better than analogue audio.
But I do suspect, in the long run, black and white might actually last longer than C41. Black and white is both much easier for a hobbiest to do and much more flexible. And it's fun. I can't see why anybody would bother with their own C41 processing, though they might possibly still have some interest in printing from colour negatives.
Rails is very secure by default (uses pepared statements and things like this).
What put me off was that Rails can't run with $SAFE = 1 or higher, and the author appears to have no intention of making it do this. That makes me nervous.
Basically, if you're using a an RDBMS rather than MySQL, and you really want to use it, Rails--or to be more precise, ActiveRecord--is not going to make you happy.
ActiveRecord is not smart about sniffing out schema information. In fact, beyond table and column names, it pretty much ignores your schema. Be prepared to re-specify all of your database constraints and relationships again.
ActiveRecord defaults to non-relational "single table inheritance" (rather than more relational class table inheritance) for hacking around the "O/R impedence mismatch." Backwards approach: this "mismatch" comes from programmers using an RDBMS outside of their code, and then trying to map the schema to something you could put into a hierarchical database internally. Well of course it can't be done easily, and sometimes not at all: that's why we're using RDBMSes instead of hierarchical databases these days.
ActiveRecord (and this is very silly) uses some tricks to use class inheritance to indicate that you want Single Table Inheritance, which means that you can't use class inheritance to move functionality around. This means that some very simple refactorings, such as pull up method, are forbidden to you. And you have to do some nasty tricks to disable this.
In short: if you really use the power of an RDBMS, ActiveRecord will hurt you. If you don't even use an RDBMS, as most ActiveRecord users don't (they use MySQL instead), it's fine.
The author of the book said in response to Ron Jeffries' review:
Interestingly, the xprogramming.com review of XPR also contains one of the most blatant Extremo claims so far - that XP "is about never needing to debug." Yegads everyone, put down those pitchforks - our silver bullet has arrived!
In my experience, Ron Jeffries is right: XP is about never needing to debug. I've been implementing some of the XP programming practices over the last few years, and the more I moved towards test-first coding, complete unit test coverage, and good automated customer tests, the less debugging I've had to do. For me, marathon debugging sessions are almost a thing of the past; perhaps once a year do I spend more than an hour debugging something, and no more than once a week, at most, do I spend more than fifteen minutes debugging something. I would never go back.
In this respect, at least, the silver bullet has arrived.
No, and it's far from new even in Japan. Au phones have had GPS and mapping applications for over a year now. This is just Docomo playing catch-up.
This is one of the failings of Slashdot; basic background information tends to be completely left out of "news" stories like this.
BTW, note that for mapping applications you also want a compass in your phone. GPS doesn't give you orientation information (AFIK--at least it didn't in the Au phones) and thus you otherwise won't see your maps oriented correctly. (All the modern Au phones include a compass.)
I don't know why people keep ignoring the first device listed. Hello! Air conditioners, folks! I come home at widely varying times that I can't predict in advance, and I know I'd *love* to be able to turn on my A/C a half hour before I arrive home.
(And yes, most air conditioners here have infrared remote controls, so you can adjust them from anywhere in the rooom.)
Ah, when lacking facts or logic, at least you can defend America with a snide tone!
At any rate, for others who might be interested, it has been translated into Japanese, and is selling all right here. It caused a bit of a stir, but mostly because a lot of this falls into that area of history they don't teach at school. (Other inconvenient bits of history include the Japanese rape of Nanking.) The history curriculum here really could use a good overhaul.
> After World War II, when we helped turn Germany and Japan > into the industrial powerhouses that they are today.
Ah, right. After WWII, when McArthur introduced strict censorship in Japan, forbidding the newspapers to write anything anything that would put America or the American occupation in a bad light.
After WWII, when McArthur decided unilaterally, without trial or even investigation, that Hirohito was not a war criminal, and, via the censorship mentioned above, rehabilitated him. This sort of "democracy" only works for emperors, it appears; many of Hirohito's associates didn't have their evidence of wrongdoing suppressed, went to trial, and were executed.
I could go on, but all the details are in John Dower's Embracing Defeat: Japan in the Wake of World War II.
Note that this "democracy" that McArthur introduced (which everyone could see was phony--though they couldn't write about it or say it out loud) is probably one of the reasons that, to this day, Japan has a teriffically corrupt electorial system and policitions. They still hand people cash for votes here.
I'm still waiting for the concept of office LAN's, firewalls, and relational databases to really catch on here.
Uh...he was joking folks. I work in lots of different offices here in Tokyo (I work for a consulting company), and I have yet to see an office without a LAN--or a firewall. Personal routers/firewalls are extremely popular; every shop sells several dozen different kinds, usually around the $200 price point. (They come with a wide variety of interfaces: Ethernet, DSL, cable, IDSN, modems, wireless.) So home networks appear to be quite popular, too.
As far as relational databases go, well, one of the biggest PosgreSQL consulting shops in the world (SRA) is Japanese, and they even happen to employ probably the most famous PostgreSQL developer. Not that I don't see plenty of Oracle around here, too.
Before I moved to Tokyo, I lived in NYC for two years, so I'm quite familiar with both. If you live in NYC, you can get an idea of what a medium-busy Tokyo line is like during rush hour by taking the Lexington Avenue line (4/5/6) southbound from, say, Grand Central to Wall St. at 8:30 or so in the morning.
As for "adding another station," I'm a bit mystified by that comment. How would you do this (in enough detail that I can see you're serious, please), and what advantage would it serve?
Or they could stop breeding like rabbits....
Um....Japan is famous for just the opposite, and it's only immigration that's keeping them out of negative population growth. (Though if they don't increase immigration even further, the population will start declining soon anyway.) Can I suggest you do two or three minutes of research before you next post?
Actually, you don't have to give valid personal information. Just buy the pass at a machine, and type in whatever you like. The only risk is that you won't be able to get a replacement card should you lose it. And I'm not convinced that they're not doing this same ID thing with the paper passes, anyway.
And very likely you're still being tracked even when you use the stored-charge-only Suica card (though not by name, of course). Everybody does it, it seems. New York's MTA has been for years tracking and storing every use of one of their magnetic-stripe cards. If you can get hold of someone's card (probably after it's run out of charge or expired), you can mail it in to them and they'll send you back a list of all the stations, dates and times where it was used. (One of the first things NYC cops will often do when they pick you up is grab your MTA card, so they can find out where you've been recently.)
> and by the way what is up with your blasted Chinese efficiency fetish?
I suspect that you have not been to Asia, and don't understand how crowded a busy train station here can be. Twenty million people commute into Tokyo every day, the vast majority of them by rail. Shinjuku station alone has three million people pass through it every day. If you save a quarter second every time a person goes through a gate, that saves you 208 gate-hours every day, which is like adding 20-30 more gates to the station.
Even the switch from paper tickets (which you slip into a slot, and which pop out another slot at the other end of the gate) to contactless cards has made a noticable difference here in Tokyo.
This photo shows a ticket gate at Shinjuku train station, though not at a particularly busy time. The fellow in the blue jacket looks like he's swiping a Suica card, but he isn't. (This picture was taken before the Suica readers were installed.)
> In a world without copyright, I still think that RMS and FSF would be happy.
I can't see how. The FSF relies on copyright to control what you may and may not do with their software. Without copyright, GNU-licensed software would become truly free*, and you'd be able to do anything you like with it.
*GNU is about free in the sense of "free beer," not "free speech." The whole point of the license is to make sure nobody ever has to pay money for the software, and your rights of speech are limited to achive this end.
Here in Tokyo, Japan Railways East introduced a contactless smart card called "Suica" last year. It's particularly convenient because one card can serve as both a stored value card and a commuter pass. When part of my trip uses the line for which I have a commuter pass, I swipe the card at the end of the journey and it deducts for only that portion of the journey that was not using my commuter line.
Unfortunately, this card, though good on JR, can't be used on the subways or private railways. But I hear that this may be coming.
The biggest cellphone provider here, Docomo, is set to introduce a contactless smart card chip in its new mobile phones later this year, which should be particularly interesting.
A huge problem that plagues CD audio (from the audiophile point of view) is the "brick wall" filter that is employed at 20KHz. This low pass filter is so sharp that it can cause some pretty nasty artifacts if it's implemented improperly (for which you should read "cheaply").
This has not been a problem for years. You just interpolate the signal up to a nice high sampling rate (say, 264.6 KHz), use a digital filter that gives you a very sharp slope and no phase shift, and then at the analogue output stage you can use a very gently sloping analogue filter with minimal phase shift to get rid of the remaining very high harmonics.
Someone should put up a note with these articles asking Americans not to assume that, just because they live in a backwards, third-rate country as far as cellphones are concerned, the rest of the world is the same.
Yes, I've sent many pieces of e-mail from my phone. As have tens of millions of the Japanese people I live with here in Japan. A few considerations:
1. Not everybody sends mail in English. The multi-tap input method works noticably better for Japanese than it does for English, which is why I tend to send e-mail in Japanese when using my phone. The pager input method is even better yet, though it has a larger learning curve.
2. There are input methods other than multi-tap that get you much closer to one keystroke per letter for western language input. In Europe already many phones use T9 text input, and there are others as well.
With the consumer Dell systems, you're right: the hardware changes from month to month. (It's not just in versions, either; you might get a completely different video or sound card in a system you order a month later.)
However, Dell (and most other major manufacturers) also sells a line of machines that are guaranteed to have the same hardware for long periods of time. The machines are noticably more expensive and less poweful. But if you know you're going to be buying two thousand of them over the next three years, and you have to do your own OS configuration and certification for every new type of machine, it makes sense to pay more for less capability.
I'm a bit surprised they even want to make Solaris. Sun has the support capabilities to roadmap and end of life for Solaris and plan to release Linux instead....
This is an insane thought. Linux is currently (and will be for quite a few years yet) a big lose compared to Solaris in many areas. The SMP is crap in comparison, it has poor hardware support on Sun hardware (or even PC hardware, for that matter), poor I18N support, the list goes on. The Linux kernel is technologically many years behind the SunOS 5 kernel.
The problem with local filtering is that if you automatically put spam in/dev/null rather than your mailbox, and a legimate e-mail is misidentified as spam, it disappears and nobody knows about it. Whereas if you bounce it, at least the sender knows the message was never delivered.
You can put it in a separate folder and examine, of course, but then you have to look at the stuff, so you might as well put it in your regular inbox. And you still stand the chance of missing a legitimate e-mail that looks too much like a spam.
cjs
Re:Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 2
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util? Would you do that?
It's even been pointed out here time and time again: one of the huge advantages of perl is the massive number of modules out there to do the work for you. People use perl for just that reason.
Anyway, I think I can put an end to the argument this way: given basically one language change (the 'char' primitive data type holds a Unicode character), and all the library changes I asked for, yes, I'd be far, far more inclined to use Ruby. So I'll just sit tight now until someone presents me with that version to compile up and run on my system, and shows me that lots of modules for that version of Ruby are becoming available, so I don't have to write much stuff from scratch....
Re:Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 2
No, these things, for all practical purposes, can't be fixed "when the time comes." The time came and went. If you're going to create some classes that are going to be reused by lots of other people, you can't go making all your methods take a StringValue rather than a String. Nobody will ever use that. (Especially when they're also confronted with another package that takes ImmutableString as parameters, and a third that takes....well, you get the idea.) You instead take the expedient, inefficent route of cloning every String parameter you get.
Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 5
Well, after a quick look at Ruby, here are some examples for annoyances:
1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)
2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?
3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.
4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.
5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.
Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.
And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)
I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.
Slashdot Mirror
This reminded me of the real reason I'm not using a digital camera: the user interface.
Perhaps if I learned to work with a really good auto-focus system I'd like it, but at the moment I prefer manual focus with a focus scale and depth-of-field indicators. (I use scale focus surprisingly often, and not just for setting the hyperfocal distance.) Many modern digital (and even many 35mm) cameras lack the focus scale, DOF indication, and comfortable controls of the older (non-auto-focus) 35mm cameras.
And I've yet to see anything with the fantastic metering interface of an Olympus OM-3 or OM-4. That's the only camera I've ever found where I can shoot practically as fast in full manual mode as I can in auto-exposure mode. (I can spot-meter three or four points, adjust shutter speed and aperture and take the shot within a few seconds, usually.) I don't have to give up the control I get with manual mode and multiple spot-meter readings in order to get speed.
If I could get that in digital, then I'd start being tempated to switch.
Unlike film cameras, digital cameras won't last any better than the computers do, at least not for many years. The basic difference is that with my 45-year-old Olympus Pen-D2, I can take advantage of all the improvements in film technology over the last 45 years, whereas with a digital camera I'm stuck. But I don't think we really care about this; who's going to complain at getting twice the camera for half the price only three or four years after buying your previous camera?
Lenses last, but become less convenient. My Olympus OM-series 100mm F2 I will put up against any lens in the world, it's that good (and I'm not the only one who's said this). But there's no auto-focus, and it would be technically tricky even to get shutter-priority AE out of it. On a modern camera, it's basically reduced to a completely manual lens. (Well, that's how it is anyway, but at least on my OM-4 I don't have to manually stop it down while metering and shooting!)
Black-and-white film negatives, if properly processed and stored, are good for perhaps a couple of hundred hears, maybe longer. We're not quite sure yet. But proper processing is a reasonable amount of work, and it is continuing work to store them properly.
Image files also take continuing work to store for long periods. (As others have pointed out, you can't just expect to slap them on a CD-ROM or tape , come back in a hundred years, and be able to read them.) But I think it's less work than storing film negatives. You could put them on a few geographically separated servers that can communicate with each other, and perhaps some off-line backups as well. It's certainly safer than keeping one's fridges running, as you're resistant to power failures, you've got multiple copies in case of disasters, all the usual stuff. If we find digital files easier to store than paper, we'd certainly find them easier to store than film.
Format conversions are a big problem with digital files. JPEG will probably be readable forever, but who wants to use JPEG? You really want to use the raw image format from the camera, or something that holds equivalant information, but camera manufacturers are pretty set these days on using proprietary formats that change and age rapidly. (Some camera manufacturers' latest software even now can't read their earliest raw files!) If we could get everyone to buy into Adobe's RAW/digital negative format the way they've bought into JPEG, that would help. At the least, for the moment, we can convert our camera raw files to that format and store both, with a JPEG copy for backup as well.
It looks to me as if, if you use proper planning, digital will be easier and cheaper to store in the long run, and will have a greater chance of surviving disasters. But, just as with film archival storage techniques, though to a lesser degree there will be on-going maintenance costs.
On the other hand, if you toss your negatives into a drawer and forget about them, they will probably be readable longer than a CD to which you do the same. But that's heavily dependent on environmental conditions: you're basically just trusting to luck, anyway.
Yes, exactly that. It took longer for digital audio to be able to deal with things like tube amps because their behavior is a lot more complex. But it's there now; pros are abandoning real tube (and even non-tube) amps for amp/speaker simulators left and right because the quality is "good enough" for most of them, and it's so much cheaper. ($800 for a tube amp, $200 for a mic, and $200 a pop for the studio setup time when you can just plug in a $200 simulator? Not a hard choice for most musicians.)
Vinyl is an interesting one. It's not that any of the DJs care whether it's analogue or digital (unlike some audio purists, who have justified complaints about some limited aspects of CD versus vinyl recording). In fact, I think the DJs would prefer digital, so that they didn't have these ridiculous issues like losing bass on an album as compared to the single because the tracks have to be closer together. (That was the main reason 12" singles were created in the first place: to try to compensate for physical issues in tracks with a lot of bass.)
Anyway, the DJs don't care about analogue versus digital; they just want the good user interface, because this is a musical instrument to them. I've only dabbled in DJing myself, but I can tell you that a Technics SLP-1200 certainly does feel a lot nicer to use than a cheap turntable, and both are nicer and more comfortable than a pro DVD player, when it comes to cuing and so on.
Perhaps the eventual solution there, as we move to audio transferred by telcom rather than physical means, will be the special records you can play on the turntables, whose output goes into a digital box, that then simulates digitally the playback of an audio file as if it were on the record. And then DJs can stop hauling large and heavy boxes of vinyl around with them, as well, instead just downloading from their home collection.
It depends on how you're trying to compete. If it's making a shot without a tripod, many relatively cheap digital cameras will beat the 10x8 for overall quality. If it's resolution, well, check out The Gigapixel Project.
Digital is pretty darn good these days, and is competing reasonably well in the 35mm world. Within five years it will likely be the better choice for all small and medium format users except those who specifically like to use chemical processes for that sake alone, or due to computer-aversion. As a photographer who does all of his own processing and printing, I may not like this, but I still don't see how black and white is going to do any better than analogue audio.
But I do suspect, in the long run, black and white might actually last longer than C41. Black and white is both much easier for a hobbiest to do and much more flexible. And it's fun. I can't see why anybody would bother with their own C41 processing, though they might possibly still have some interest in printing from colour negatives.
Rails is very secure by default (uses pepared statements and things like this).
What put me off was that Rails can't run with $SAFE = 1 or higher, and the author appears to have no intention of making it do this. That makes me nervous.
Basically, if you're using a an RDBMS rather than MySQL, and you really want to use it, Rails--or to be more precise, ActiveRecord--is not going to make you happy.
ActiveRecord is not smart about sniffing out schema information. In fact, beyond table and column names, it pretty much ignores your schema. Be prepared to re-specify all of your database constraints and relationships again.
ActiveRecord defaults to non-relational "single table inheritance" (rather than more relational class table inheritance) for hacking around the "O/R impedence mismatch." Backwards approach: this "mismatch" comes from programmers using an RDBMS outside of their code, and then trying to map the schema to something you could put into a hierarchical database internally. Well of course it can't be done easily, and sometimes not at all: that's why we're using RDBMSes instead of hierarchical databases these days.
ActiveRecord (and this is very silly) uses some tricks to use class inheritance to indicate that you want Single Table Inheritance, which means that you can't use class inheritance to move functionality around. This means that some very simple refactorings, such as pull up method, are forbidden to you. And you have to do some nasty tricks to disable this.
In short: if you really use the power of an RDBMS, ActiveRecord will hurt you. If you don't even use an RDBMS, as most ActiveRecord users don't (they use MySQL instead), it's fine.
cjs
The author of the book said in response to Ron Jeffries' review:
In my experience, Ron Jeffries is right: XP is about never needing to debug. I've been implementing some of the XP programming practices over the last few years, and the more I moved towards test-first coding, complete unit test coverage, and good automated customer tests, the less debugging I've had to do. For me, marathon debugging sessions are almost a thing of the past; perhaps once a year do I spend more than an hour debugging something, and no more than once a week, at most, do I spend more than fifteen minutes debugging something. I would never go back.
In this respect, at least, the silver bullet has arrived.
cjs
No, and it's far from new even in Japan. Au phones have had GPS and mapping applications for over a year now. This is just Docomo playing catch-up.
This is one of the failings of Slashdot; basic background information tends to be completely left out of "news" stories like this.
BTW, note that for mapping applications you also want a compass in your phone. GPS doesn't give you orientation information (AFIK--at least it didn't in the Au phones) and thus you otherwise won't see your maps oriented correctly. (All the modern Au phones include a compass.)
I don't know why people keep ignoring the first device listed. Hello! Air conditioners, folks! I come home at widely varying times that I can't predict in advance, and I know I'd *love* to be able to turn on my A/C a half hour before I arrive home.
(And yes, most air conditioners here have infrared remote controls, so you can adjust them from anywhere in the rooom.)
cjs
Ah, when lacking facts or logic, at least you can defend America with a snide tone!
At any rate, for others who might be interested, it has been translated into Japanese, and is selling all right here. It caused a bit of a stir, but mostly because a lot of this falls into that area of history they don't teach at school. (Other inconvenient bits of history include the Japanese rape of Nanking.) The history curriculum here really could use a good overhaul.
cjs
> > When was this?
> After World War II, when we helped turn Germany and Japan
> into the industrial powerhouses that they are today.
Ah, right. After WWII, when McArthur introduced strict censorship in Japan, forbidding the newspapers to write anything anything that would put America or the American occupation in a bad light.
After WWII, when McArthur decided unilaterally, without trial or even investigation, that Hirohito was not a war criminal, and, via the censorship mentioned above, rehabilitated him. This sort of "democracy" only works for emperors, it appears; many of Hirohito's associates didn't have their evidence of wrongdoing suppressed, went to trial, and were executed.
I could go on, but all the details are in John Dower's Embracing Defeat: Japan in the Wake of World War II.
Note that this "democracy" that McArthur introduced (which everyone could see was phony--though they couldn't write about it or say it out loud) is probably one of the reasons that, to this day, Japan has a teriffically corrupt electorial system and policitions. They still hand people cash for votes here.
cjs
Uh...he was joking folks. I work in lots of different offices here in Tokyo (I work for a consulting company), and I have yet to see an office without a LAN--or a firewall. Personal routers/firewalls are extremely popular; every shop sells several dozen different kinds, usually around the $200 price point. (They come with a wide variety of interfaces: Ethernet, DSL, cable, IDSN, modems, wireless.) So home networks appear to be quite popular, too.
As far as relational databases go, well, one of the biggest PosgreSQL consulting shops in the world (SRA) is Japanese, and they even happen to employ probably the most famous PostgreSQL developer. Not that I don't see plenty of Oracle around here, too.
cjsBefore I moved to Tokyo, I lived in NYC for two years, so I'm quite familiar with both. If you live in NYC, you can get an idea of what a medium-busy Tokyo line is like during rush hour by taking the Lexington Avenue line (4/5/6) southbound from, say, Grand Central to Wall St. at 8:30 or so in the morning.
As for "adding another station," I'm a bit mystified by that comment. How would you do this (in enough detail that I can see you're serious, please), and what advantage would it serve?
Or they could stop breeding like rabbits....
Um....Japan is famous for just the opposite, and it's only immigration that's keeping them out of negative population growth. (Though if they don't increase immigration even further, the population will start declining soon anyway.) Can I suggest you do two or three minutes of research before you next post?
cjs
Actually, you don't have to give valid personal information. Just buy the pass at a machine, and type in whatever you like. The only risk is that you won't be able to get a replacement card should you lose it. And I'm not convinced that they're not doing this same ID thing with the paper passes, anyway.
And very likely you're still being tracked even when you use the stored-charge-only Suica card (though not by name, of course). Everybody does it, it seems. New York's MTA has been for years tracking and storing every use of one of their magnetic-stripe cards. If you can get hold of someone's card (probably after it's run out of charge or expired), you can mail it in to them and they'll send you back a list of all the stations, dates and times where it was used. (One of the first things NYC cops will often do when they pick you up is grab your MTA card, so they can find out where you've been recently.)
cjs
I suspect that you have not been to Asia, and don't understand how crowded a busy train station here can be. Twenty million people commute into Tokyo every day, the vast majority of them by rail. Shinjuku station alone has three million people pass through it every day. If you save a quarter second every time a person goes through a gate, that saves you 208 gate-hours every day, which is like adding 20-30 more gates to the station.
Even the switch from paper tickets (which you slip into a slot, and which pop out another slot at the other end of the gate) to contactless cards has made a noticable difference here in Tokyo.
This photo shows a ticket gate at Shinjuku train station, though not at a particularly busy time. The fellow in the blue jacket looks like he's swiping a Suica card, but he isn't. (This picture was taken before the Suica readers were installed.)
cjs
> In a world without copyright, I still think that RMS and FSF would be happy.
I can't see how. The FSF relies on copyright to control what you may and may not do with their software. Without copyright, GNU-licensed software would become truly free*, and you'd be able to do anything you like with it.
*GNU is about free in the sense of "free beer," not "free speech." The whole point of the license is to make sure nobody ever has to pay money for the software, and your rights of speech are limited to achive this end.
cjs
Here in Tokyo, Japan Railways East introduced a contactless smart card called "Suica" last year. It's particularly convenient because one card can serve as both a stored value card and a commuter pass. When part of my trip uses the line for which I have a commuter pass, I swipe the card at the end of the journey and it deducts for only that portion of the journey that was not using my commuter line.
Unfortunately, this card, though good on JR, can't be used on the subways or private railways. But I hear that this may be coming.
The biggest cellphone provider here, Docomo, is set to introduce a contactless smart card chip in its new mobile phones later this year, which should be particularly interesting.
cjs
cjs
1. Not everybody sends mail in English. The multi-tap input method works noticably better for Japanese than it does for English, which is why I tend to send e-mail in Japanese when using my phone. The pager input method is even better yet, though it has a larger learning curve.
2. There are input methods other than multi-tap that get you much closer to one keystroke per letter for western language input. In Europe already many phones use T9 text input, and there are others as well.
cjs
With the consumer Dell systems, you're right: the hardware changes from month to month. (It's not just in versions, either; you might get a completely different video or sound card in a system you order a month later.)
However, Dell (and most other major manufacturers) also sells a line of machines that are guaranteed to have the same hardware for long periods of time. The machines are noticably more expensive and less poweful. But if you know you're going to be buying two thousand of them over the next three years, and you have to do your own OS configuration and certification for every new type of machine, it makes sense to pay more for less capability.
You can put it in a separate folder and examine, of course, but then you have to look at the stuff, so you might as well put it in your regular inbox. And you still stand the chance of missing a legitimate e-mail that looks too much like a spam.
cjs
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util? Would you do that? It's even been pointed out here time and time again: one of the huge advantages of perl is the massive number of modules out there to do the work for you. People use perl for just that reason. Anyway, I think I can put an end to the argument this way: given basically one language change (the 'char' primitive data type holds a Unicode character), and all the library changes I asked for, yes, I'd be far, far more inclined to use Ruby. So I'll just sit tight now until someone presents me with that version to compile up and run on my system, and shows me that lots of modules for that version of Ruby are becoming available, so I don't have to write much stuff from scratch....
No, these things, for all practical purposes, can't be fixed "when the time comes." The time came and went. If you're going to create some classes that are going to be reused by lots of other people, you can't go making all your methods take a StringValue rather than a String. Nobody will ever use that. (Especially when they're also confronted with another package that takes ImmutableString as parameters, and a third that takes....well, you get the idea.) You instead take the expedient, inefficent route of cloning every String parameter you get.
1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)
2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?
3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.
4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.
5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.
Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.
And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)
I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.
cjs