It's easy to simply dismiss this as poor management (and it is), but solving the problem is often a bit trickier than replacing the manager. The biggest problem is that a really large segment of the software industry does not know how to connect business goals with software development activities. It's not just the managers who are clueless, but also the programmers. Many programmers do not consider business goals further than, "If I do things *right* then it will be better in the long run" (for various descriptions of the words "right" and "better").
What I've tried to do in the past is to encourage my manager to worry exclusively about business goals while I worry exclusively about maximizing through put. It's important to stress to the manager that you want to achieve maximum through put, not just maximum velocity. If you are running a marathon, it does you no good at all to break the world record in the 100 meter dash. You need to achieve the highest *average* speed possible over the entire course. This is done by intentionally slowing down and paying attention to things other than that when running a short distance. It's important to illustrate that the world record holder in the 100 meter dash would probably finish a marathon several times slower than even an average marathon runner.
Having said that, there really are times when you have to sprint. It does you no good at all to get tremendous throughput and finish on Friday when the company runs out of money on the Monday before. But just like a sprinter, after we sprint, we have to stop and recover. Sprinting continuously leads to death.
What I tend to do is to be very respectful when my manager asks me to sprint. I tell him that we will be happy to sprint for him. I tell him how far we can sprint and how fast we are likely to be able to run. I tell him the cost in terms of productivity (i.e., after this sprint, we have to stop and spend at least an equivalent time recovering). I let him choose, because that's his area. If he says we have to do something that I think is impossible, I agree to try my best. But I ask him to find another business plan, because this one will almost certainly lead to failure. It's his call and after he makes it, I will never say another word about it.
Finally, if my manager tells me that he thinks we can go faster with another method, I will certainly listen to his ideas. If I disagree, I will tell him that I don't think it's a good idea. Getting the highest productivity that meets the business goals is my job. If he does not have confidence in my ability to do that job, then he should certainly find someone else for the job.
Once we have an understanding in place, I've never had any trouble introducing any development practice I want. But my ass is on the line if we don't hit the business goals. And that's the way it should be.
I've always wanted to write "tests" in a literate way. For me tests are a way to document the behaviour that I expect and various assumptions along the way. If the behaviour changes, or if I do something that disregards the assumptions I made, I want the tests to fail.
I feel that I *should* be able to organize this in a literate way. If I want, I can even write human language documentation in the same place. The testing framework provides the same purpose that Web (or its equivalent) would -- it allows me to organize my discussion by design or by behaviour. The added benefit is that it is executable and so tells me if the production code is meeting my expectations. It also has the benefit of providing examples of how I expect the code to be used.
The problem that I tend to run into is that I have too much coupling between the implementation and the tests. As I refactor code, the discussion I make with the tests drifts and I end up having to refactor the tests considerably more than the production code. To combat this, I have made a practice of separating my unit tests from my larger scale behavioural tests, but I still end up with a lot of churn whenever I'm refactoring. Because of this churn, it's quite easy to lose track of where I'm discussing what issue and my ability to use the tests as literate documentation slowly disintegrates.
I've never actually done literate programming in the proper sense, so I wonder if people who do run into the same issues. I suppose it is possible they just try to avoid refactoring, which would be unfortunate.
I like to post as Anonymous Coward as much as the next guy (probably more so), but if you're going to post about your project and reply to questions in the thread, could you create an ID (if only for this discussion)? It would make it much, much easier to track what you are saying (and separate it from people who might try to impersonate you).
Anyway, thanks for the work on the graphics driver. This is an area that sorely needs developers. Every little bit helps. I hope your employer understands the difference between advancing the state of open source software and helping your competitor. I suspect you might find that you have stepped on a few toes, though. Soulskill didn't do you any favours in writing the summary, unfortunately:-(
I think you are over generalizing. Different approaches are good for different people. The summary says that the boy wants to learn on his own. He's probably fairly self motivated. When I was a kid I was the same. My father offered to teach me to program, but I wanted to do it myself. He threw me a textbook for a first year introductory university course and I read it cover to cover. I loved every page of it. I started out writing stupid text games, but I never really played them. I just liked programming. There are people (even kids) who don't want to be constrained by how someone else thinks they should learn.
C, Python, Ruby, Java, and even LISP based languages are all fine. The second language I learned was FORTH and it was fun. I might not throw them generative style C++ out of the gate, but for me learning every new style of programming was like an adventure. It really just depends on the person. Both syntactically and semantically programming languages are conceptually a lot simpler than human languages, but we throw our kids into foreign language study with abandon. We don't make them learn Esperanto because Spanish is too hard.
I don't disagree with your main thesis, but i don't think you could implement a system with Bitcoin the way you describe necessarily. Bitcoin relies on the idea that the compute power necessary to fake the block chain is more expensive than the benefit your receive for participating in creating the correct block chain. This is why people receive bitcoins for "mining". There has to be an incentive to mine that is higher than the cost of cheating. With Bitcoin as it stands now, the reward for solving the block chain is enough incentive. But if you vastly increase the amount/size of transactions, the incentive for cheating increases. This means you have to increase the reward for participation. Bitcoin's method for doing this is to have transaction fees. But I suspect that people will not be willing to pay enough fees, especially for small transactions.
I may be totally wrong (I haven't researched this at all), but my assumption about China subsidizing PV panels is that it's probably similar to what happened with RAM back in the day (I'm too old to remember when it happened -- get off my lawn!). Basically, Asian RAM manufacturer's undersold the American's due to subsidies. This caused all the American manufacturer's to go out of business. By the time the American's added duties to RAM, the cost of production in the large factories had fallen to the point where the Asian manufacturers no longer needed subsidies. With massively huge factories, they could be profitable at the previous low prices. The American's, on the other hand, would need to invest huge amounts of capital to build factories big enough to compete. And they never did.
In other words, the subsidies are there to build up production to the point where the the cost of entry to the market is too high for anyone else to come in.
IMHO, the effect of tariffs on PV panels will be similar to the effect of tariffs on RAM. It will raise prices in the US, but it won't protect the market.
I assume the OP means $1 for the cost of a solar panel which has a peak generation capacity of 1 watt. So in other words, the cost of a solar panel that has 1 kW of peak generation capacity is $1000 (I assume not including installation). That's what's normally meant by $x per watt. As you can imagine, solar panels do not have an operational cost, so it doesn't make sense to discuss the cost of solar power in terms of x kWh per month. After installation, it's free (well largely, anyway).
Normally you have a tie in with the local utility where you provide excess power that you generate during the day (when overall demand is high) and you take back some at night when you can't generate power. The local utility has to provide power up to the peak demand during the day. Having other producers supply power during that peak time allows them to scale back their equipment.
A solar panel rated at 1 kW of of peak generation will obviously not generate 24 kWh of electricity a day. It depends on location, how sunny it is, the season, what kind of installation you have, etc. But let's assume you can get 3 kWh of electricity from a 1 kW solar panel. You use about 12 kWh of electricity a day. So you would need 4 of these panels (or about $4000 at the OP's prices). You also have to pay for installation, so let's say $6K total. If you amortized that cost over the 20 year expected lifetime of the panels, you're talking about $46 per month at 7 percent interest, compounded monthly.
So, if the cost is correct, the OP's assertion seems to hold up. Where I live electricity is pretty near 40 cents per kWh (3 times what you pay) and we have a lot of sun. Solar panels are extremely popular these days. You can even buy them at the local hardware store. (Note that 3kWh per day is probably pretty optimistic for most locations, but you get the idea). As soon as I get my own roof, I will definitely be buying.
It's not so easy to change your name in Japan. First, your name is recorded in a family register. All citizens of Japan must be in a register. If you aren't you lose a lot of legal rights. When you get married, you *must* have the same name as your spouse, though either the man or the woman can change their name. When you change your name you must change it to your spouse's name. You can't make up a new one.
There are a few other times where you are allowed to change your name in the register, but you can't do it arbitrarily. I don't understand the rules. At the moment, I'm getting married and my fiance wants to use my (non-Japanese) name. My name is hard to pronounce in Japanese and I would like to use similar but different sounds from the usual transliteration. Even that looks like it will be impossible.
I haven't RTFA yet. I'm not sure what could have transpired to get the guy fired. Once the misunderstanding was cleared up, it shouldn't have been a problem. But once you loose your job in Japan, it is *very* difficult to get another one, dodgy name or not. His lack of ability to find a new job may be completely unrelated to the google searches.
Not sure you will see this, but I wanted to say that I looked at your code. I didn't spend nearly enough time on it to make a fair comment on it, but writing open source code is a great way to get feedback on your code. I definitely get the same feeling on my own project (http://jldrill.rubyforge.org/) with respect to "perfect is the enemy of new features". Often I need a feature and I simply don't have enough time to implement it well. Those kinds of short term and long term tradeoffs are tricky. The term "technical debt" is a popular one and describes the issue well, I think. Sometimes you can dip into debt, but if you don't repay it quickly enough, it can sink your project.
If there's one thing that I would suggest thinking about it's that there is almost certainly a sweet spot where attention to detail, while initially slower, improves productivity throughput overall. Things like writing unit tests can double your implementation time, but over the long run it may end up being significantly faster than not doing it (Actually, I will say that when done properly, this is almost certainly true). Additionally, there are subtle design issues that if you make a mistake, it can cost you a fair amount of time either through the resultant complex code, or though the need to refactor.
Training is really important. My little project is training for me. There is lots of crap code in there, either from failed ideas, experiments gone wrong, or just plain being too tired to do it correctly. But by working on it and being very attentive to what sucks I can make pretty good gains in my own ability to find appropriate designs quickly. You can't really do that on a work project because it is inappropriate to experiment that way. Looking at your code, I get the impression that you also get a lot of personal benefit from working on your project.
Very interesting point of view. You are probably correct. I am probably projecting my own sense of values on RMS's thoughts. I will have to reflect on it a bit.
The reason I say that is because, while I get your point, often RMS communicates in a rather blunt manner (IMHO anyway). It's not impossible for an astro-turfer to concoct an RMS-like quote that looks plausible but contains certain phrases that trigger "nutjob" knee-jerk reactions in people. Being able to point to the actual interview helps to show that it is authentic.
Unfortunately, I don't think he does himself any favors in this interview. Like you, I largely agree with him, but I wish that he would take some advice on effective methods of getting his message across. His use of the word "ethical" is troublesome. I think I understand what he means, but I guarantee that many people will interpret it as meaning that they are "unethical" if they don't run free software. I don't think that is what is intended (I might be wrong, I suppose). As a movement geared to *help* the user, using software that isn't free is unfortunate, but hardly unethical.
A free software community is powerful because instead of being consumers, the user is enabled to be a producer. If the software is not free, they are blocked from contributing (even if it is only to help themselves). If users choose software that isn't free because it is more capable, they get more capable software, but can't form a community of enabled users. They can't help themselves; they can help their friends and they can't be helped by their friends (or some random guy half way around the world who happens to have the same problem). Everything must come from one controlling entity. If they decide not to help (or decide to charge you ridiculous amounts of money), then you are screwed.
I suspect RMS thinks that people already understand this and simply says that free software is a matter of ethics to drive home his point. Unfortunately, I think many people completely miss the point and instead become insulted. It ends up having the opposite reaction that was intended.
For me the most important thing was having a presence. I had an IM client going all the time and was religious about updating my presence. If I was at the keyboard, it was obvious to anyone in the office. If I was away, it was obvious to everyone in the company. I was scrupulously honest about what I was doing. If I wanted to take a nap (which is easy to do from home), my status said, "Having a nap". Nobody cares what you do, but it can bother them if they don't know what it is. At work my manager can look over the cubicle wall and see that I'm at my desk. It can be uncomfortable if they can't do the same when teleconferencing.
A couple of other people mentioned IP phones. I agree with this. Video is great too (as long as you have clothes on). You want to make your home office as approachable as your work cubicle. People can look to see if you're there, they can wander in to ask a quick question, or just shoot the shit. Even small things like checking in your code frequently (every hour or so) makes people realize you are there and gives them an indication for what you are working on.
Sometimes you might think, "They don't *have* to know what I'm doing all the time." This is true, but the more different you are from the rest of the team, the harder it is for them to think of you as being on the team.
One more quick tip. In my office there were a couple of shared responsibilities like cleaning the kitchen, etc. I used to come in once every couple of weeks for a face to face. When I was there, I always took a turn on those shared responsibilities. I don't benefit from them, but its just another way to show that I'm part of the team. Small things like this made a big difference, I think.
I'd love to work from home again. I was incredibly productive. Right now I'm doing a different kind of job, but if I go back to programming (considering it) it would definitely be nice.
i've been coding for 8 years and as long as your code is maintainable, works, commented, and capable, you're doing a good job. also, for the love of god, don't hardcode your file paths or operating system. use a standard library, never do a system call. when you have do, error check it.
It's hard to comment based solely on what you have written because I've never seen your code. But I have to question the level to which you are aspiring. There is a huge gulf in quality between code that works and code that is minimal and obvious. You say "maintainable, works, commented and capable". Unfortunately, that could describe code that is barely acceptable all the way up to excellent. I don't really know what you mean, so this might be superfluous to you.
Code that works and is understandable is the minimum quality of code that I think is acceptable. But when you are designing (or refactoring) code, the decisions you make can have a large impact on the rest of the system. Because I read a lot of the original papers on design patterns, I tend to think of code as having a shape (a lot of the earlier descriptions used this kind of metaphor). Code that has an appropriate shape fits nicely with the rest of the code. It has a minimal complexity (i.e., the code is no more complex than the problem it is trying to describe). It also doesn't complicate other code that needs to talk to it.
On the other hand, code with a shape that is not appropriate does not fit in. It introduces complexity based on its shape alone (independent of the problem it is trying to solve). Code that needs to talk to it often has to do something extra, or carry around some extra data to make it work. This creates an inappropriate shape for this new code. When you have one thing that doesn't fit well, it can have a ripple effect that increases complexity all through the code. Not only that, but there can be a multiplying effect. Each work-around that you introduce to accommodate inappropriate code causes more and more complexity.
When I look at large software projects, most of the complexity usually comes from dealing with other code rather than solving the problem. The more code you have, the more complex your system becomes. Most software projects actually solve simple problems, but are still very, very complex. You might think that there is nothing you can do about this, but if you look at system libraries they often simplify your life. This seems opposite to the "more code = more complexity" argument. The difference is that these system libraries usually have an appropriate shape for what they are doing.
Your advice is generally sound. Learning to use appropriate idioms, learning to use appropriate reuse libraries, writing understandable, working code is the basis of programming. But there is another level beyond this. Choosing appropriate code shapes, keeping complexity to a minimum, understanding trade-offs of coupling and cohesion -- This is quite hard and requires a fair amount of practice. Excellent code is not just maintainable and documented, but also minimal and obvious. When other code interfaces with excellent code, it is easy to do so and it introduces a minimum of extra complexity.
IMHO, you should strive for this. If you think that you already accomplish this without thinking about it, then I invite you to look again. I suspect you may be overlooking something.
It's going to be nigh impossible to get anyone to review your work code, even though they should.
This is unfortunately all too true in most cases. Most organizations do not understand the benefit of rigorous code reviews. If they review code at all, they often only look to see if there are bugs, or if (usually fairly arbitrary) coding standards are followed. I've been lucky enough to work on a few teams with brutally honest reviews. It can be intimidating, but in the end it is incredibly useful for developing yourself. Things like pair programming can also be very useful in this regard.
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
For some reason, I often think about programming teams as if they were sports teams. The way most teams are run, you have a manager who knows little about the game you are trying to play and never watches a game. There are no coaches. You performance is loosely evaluated on whether or not your team wins games, but even then the manager usually tries to make it appear that the team won every game whether they did or not. When they try to get new players, they don't bother looking at the success of the player on their previous teams, or even watch them play. At most they set up some artificial 5 minute drill and evaluate that, but usually they base their decisions on a feel-good interview.
It's quite literally crazy IMHO. In the case of sports it is obvious that this isn't going to work. I'm not sure why it isn't obvious for programming teams.
When asked this question, I often think, "How do aspiring writers learn their craft?" People who study English read ridiculous numbers of books. This gives them a base to start from when they are writing.
Writing your own code is invaluable, but when you are just starting out it helps not only to contribute to open source projects, but also to read, read, read. I recommend going through some interesting projects and then forming an opinion about which ones have the best code. Don't just look at it superficially; try to form opinions on specific practices, idioms and designs. Then choose a project to work on and try to follow those ideas. From that point the feedback will be more valuable.
One of the things that Kent Beck said one time (possibly in an interview with Floss Weekly; I can't remember) was that his level really improved when he sat down and really thought about what he was doing. He just kept writing things over and over again until he could say exactly why he did everything. IIRC, he wrote down all his ideas and put it in a book on Smalltalk coding practices (which I haven't read yet...) I've been trying to do the same thing lately and it is really beneficial. Forming your own ideas and *then* getting feedback seems to be more productive than writing "just to make it work" and getting feedback.
Just be open minded when you think you have it all sorted out, but someone else thinks your ideas suck;-)
Indeed. And it can lead to strange effects. The other day I was listening to some music on the radio (I forget what) where the singer started out with what was probably a quiet solo. After a while the orchestra swelled in the background. The singer's voice should have increased in volume to sing over top of the orchestra, but because the music was so heavily compressed, their voice actually diminished in volume while still being over top of the orchestra. The overall volume stayed the same.
I remember thinking, "Well, that's bizarre". It completely ruined the song. The soft, quiet part was annoyingly loud, with the singer's voice piercing my eardrums, and as the song built momentum and energy, the singer kept getting quieter and quieter.
You are missing an important word: he *reasonably* believed that he was selected because of his sexual orientation.
Just because someone believes they are being targeted would not be enough. You would have to give them some reason to believe they are being targeted.
It is true that it is possible to commit the crime without an intent to commit the crime. But this happens with other laws too. If I drive drunk, I may have no intent to kill someone, but if I do, I am still criminally at fault. People *do* have to be careful of their actions. You can't just do whatever you want to do. You have to think about the impact of your actions on others. If you don't, there are circumstances in which you will break the law. Specifically, if you cause harm to someone through your own negligence, even though you didn't intend to do it, you are still responsible.
In the case of preachers preaching against homosexuality, there are cases where it can cause harm. IANAL, but if someone were to say, "Homosexual's are evil and we must cast them from our society", I would suspect that they could be held criminally responsible if someone acted on that and started physically removing people from the community.
I think one of the areas where the law can be improved is that we tend to categorize things too much. Causing harm by targeting a population for their sexual orientation is illegal in many places. Causing harm by targeting slashdot readers may not carry the same penalty. There is probably some legal reason for this, but I don't really understand it.
I actually live in a country with no such laws (as far as I know). In Japan, while very uncommon, you can still see signs that forbid racially non-Japanese people from entering. I have been denied service twice at stores because I am not racially Japanese. I have very occasionally seen black vans drive by with megaphones shouting that foreigners must be made to leave. None of this is illegal as far as I know. Nothing in the law says you have to give service to every potential customer who walks up. Nothing in the law says that you can't say whatever you want to say (even through a loud megaphone, apparently -- that part is unfortunate at election times). It doesn't really bother me because it is incredibly rare. But if it happened all the time, even if no one person was breaking the law, it would be too much to bear. If *everyone* denied me service because I am white, I couldn't buy food. If *everyone* yelled at me and told me to get out because I was white, I could never relax.
It is specifically the targeting that is (and should be, IMHO) illegal. If you want to deny someone service, or if you want to tell them to get out of the country you should have to make an effort to show that you aren't targeting that person due to some class that they belong to. Targeting classes of people and causing harm to them also causes harm to society. Even if you didn't intend to target a class of people, but gave every reason to believe that you were, you still cause harm to society. This is why it is (and should be, IMHO) illegal.
I often get confused when people talk about "liberal" this and "conservative" that. From my non-American perspective, I see so little difference between the two that I can't bring myself to acknowledge that there is a substantive difference.
What the two "sides" tend to do is report an issue and exaggerate a piece of minutia, a nuance, or some abstract principle. They then blow that one thing up out of all proportion and highlight specifically how it is different from "other side". Finally, they leave the viewer with the impression that if everyone doesn't agree on this tiny bit of minutia, the whole world will go to hell in a hand basket. You *must* oppose the other side with all your heart.
They intentionally create a distinction in order to separate the two sides and give an illusion of choice.
But I would caution that the internet is far from free of that meme. If anything it can be worse if all you read is opinion. The one advantage is that it can sometimes be easier to trace down facts in order to create your own opinions. But verifying the facts is not trivial.
Similarly, if you are writing client code (or pretty much anything interactive), the program is spending the vast majority of its time waiting on the user. I have some Ruby code where I have to read in and parse some pretty big files. What I realized was that I could read the file into memory, quickly index the data and leave the majority of the parsing for later. The user isn't going to notice if I slow down giving results from 0.01s to 0.1 seconds when it takes them 2 seconds read the data.
Totally off topic, but it is very true that there are extremely capable people all over the world (not just India). These capable people will often work for much less than capable people in more "developed" countries. My experience has been that the problem with outsourcing to these capable people is that software development is a task requiring a lot of communication. Outsourcing parts of the process is almost always a disaster. You need to outsource the entire thing (middle management, QA, project management, documentation, etc, etc).
There is also one other problem. I've worked for a so-called "body shop" before in Canada. These consulting companies do not hire in the same way that an ordinary company would hire. They aren't looking to fill specific roles, but rather they want a hodge-podge of skills that will enable them to win contracts. Then, when they are trying to fill a contract, they don't put members on the team with the thought of creating success, but rather with the thought of keeping a range of skills available to win other contracts. The resultant teams can often be non-functional.
I think it is entirely possible to reduce development cost by moving development to a cheaper location. But you have to move lock, stock and barrel and hire permanent teams in the same way that you would do in your home country. Outsourcing only a part of your development to an agency in a far away, foreign country is pretty much a recipe for failure.
Drawings are not generally considered to be child pornography in Japan (the only place where I wouldn't be sure is if you were drawing an actual event).
The vast (really vast, vast, vast) majority of manga in Japan contains nothing that would be considered pornographic in Japan. There are certain magazines and books which contain pornography. Some of those contain drawings of children, though AFAICT the majority of those are of high school kids (I'm not an expert!). Some book stores will stock pornographic magazines, fewer of those stock the magazines that regularly have drawings of children. It's not terribly difficult to buy these things, but generally you have to go to a store which specializes in fringe interests. There is a large negative bias in the general population, from my experience.
Where you get into trouble is more mainstream manga/anime which has occasional nudity. Drawings of people bathing are relatively common (Kagome in Inuyasha, said to be 14 is naked in the first volume; Bulma in Dragon Ball, said to be 16 is naked in the first volume; etc). Japanese people think nothing of this, in general. Nakedness isn't unusual.
I hesitate to mention it (for fear that someone will misinterpret it), but in the onsen (hotsprings), fathers often bring their pre-teen daughters with them into the men's side. Nobody bats an eyelid. It's not a big deal. Drawings of the same thing, even if meant to be slightly titilating are not considered to be offensive. But I can imagine getting into huge amounts of trouble owning these drawings in Canada or the US.
What's incredibly scary for me is that it is easier than people might think to get caught by this. I live in Japan and my friend's daughter (who lives in Canada) asked if I could mail her a manga so that she could practice reading Japanese. Her favorite anime at the time was Inu Yasha.
No problem! I bought the manga, was all ready to mail it off when I thought, "Hey, I haven't read this for a while, maybe I'll just give it a read". Half way through the book, there's a picture of the main character (a 14 years old girl) taking a bath in the lake. Not an erotic scene IMHO, but I guarantee it meets the definition of child porn in Canada.
That's just what I need; to have a record for importing child porn to Canada.
Definitely tongue in cheek. I once went to the Canadian National Gallery and they had a modern art exhibit. One of the exhibits was a reel-to-reel tape recording of a waterfall, cut up into pieces and stuffed in water bottles. I thought it was a clever idea, but I didn't consider it to be particularly good from an art perspective.
On the other hand they had another exhibit where the artist wrote a set of requirements for what he wanted on index cards. He then gave the index cards to his students and asked them to collaborate to create the art. The result was awful. There was even a letter by the artist describing how disappointed he was in the resultant piece. He said that before the experiment he had a high opinion of his students and that their inability to use common sense to create a piece of artwork based on his instructions made him question that.
I think a lot of people would look at that exhibit and think, "Meh...". For me, I thought it was absolutely brilliant. This exhibit captured the essense of the problem people face when making collaborative projects like software. It was incredible.
Art often requires the viewer to have a certain perspective before it is effective. A set of colorful horizontal lines is completely meaningless to me and "bad art". I can actually understand that it is "brilliant" to someone else who has a different perspective.
A lot of the current research points at reading as being a very effective means of language acquisition. You have to read a lot, though (more than most people would do -- 2-4 million words a year). Choosing books at an appropriate level is also difficult. People almost universally choose books at a level that is far too high. People who have learned a language up to the level of a 5 year old are considered "advanced" speakers (6,000 words of vocabulary and all the basic grammar). They are often dismayed when they can't even read a book aimed at elementary school children (which is, by definition, far above their level). I'm lucky in that Japan has a vibrant comic book culture and I can find a huge number of level appropriate, conversationally oriented books to read. Unfortunately a lot of language learners consider doing these kinds of things somehow beneath them and childish.
I appreciate you having read all my long typing:-) I think you are correct that I need to find a more appropriate word where I'm using "easy". I'll have to think about it. I just want to reiterate that you *can* learn another language to a very high level of fluency. Just keep in mind that most of the language learning educational system is stuck behind ancient and largly inefficient methods of language acquisition. I teach English to Japanese kids as my day job. My colleagues are all fluent in English. I often ask them if the method of learning they teach was effective for them in acquiring English. Without exception, they say that their success in learning English came by a completely different method. Don't be afraid to throw the textbook out (or rather, unless you are finding it is working for you, please throw it out -- it will only slow you down). All you require to learn a language is that you understand what you are hearing/reading, that you get enough volume of input to learn at a reasonable rate, and that you get enough repetition at the correct times to retain what you've learned. I have found that a dictionary, grammar dictionary and a huge pile of books is enough. There are, of course, other things you need to do for pronunciation, etc (I do karaoke in Japanese, watch TV, etc, etc), but you are really only limited by your imagination.
Slashdot Mirror
It's easy to simply dismiss this as poor management (and it is), but solving the problem is often a bit trickier than replacing the manager. The biggest problem is that a really large segment of the software industry does not know how to connect business goals with software development activities. It's not just the managers who are clueless, but also the programmers. Many programmers do not consider business goals further than, "If I do things *right* then it will be better in the long run" (for various descriptions of the words "right" and "better").
What I've tried to do in the past is to encourage my manager to worry exclusively about business goals while I worry exclusively about maximizing through put. It's important to stress to the manager that you want to achieve maximum through put, not just maximum velocity. If you are running a marathon, it does you no good at all to break the world record in the 100 meter dash. You need to achieve the highest *average* speed possible over the entire course. This is done by intentionally slowing down and paying attention to things other than that when running a short distance. It's important to illustrate that the world record holder in the 100 meter dash would probably finish a marathon several times slower than even an average marathon runner.
Having said that, there really are times when you have to sprint. It does you no good at all to get tremendous throughput and finish on Friday when the company runs out of money on the Monday before. But just like a sprinter, after we sprint, we have to stop and recover. Sprinting continuously leads to death.
What I tend to do is to be very respectful when my manager asks me to sprint. I tell him that we will be happy to sprint for him. I tell him how far we can sprint and how fast we are likely to be able to run. I tell him the cost in terms of productivity (i.e., after this sprint, we have to stop and spend at least an equivalent time recovering). I let him choose, because that's his area. If he says we have to do something that I think is impossible, I agree to try my best. But I ask him to find another business plan, because this one will almost certainly lead to failure. It's his call and after he makes it, I will never say another word about it.
Finally, if my manager tells me that he thinks we can go faster with another method, I will certainly listen to his ideas. If I disagree, I will tell him that I don't think it's a good idea. Getting the highest productivity that meets the business goals is my job. If he does not have confidence in my ability to do that job, then he should certainly find someone else for the job.
Once we have an understanding in place, I've never had any trouble introducing any development practice I want. But my ass is on the line if we don't hit the business goals. And that's the way it should be.
I've always wanted to write "tests" in a literate way. For me tests are a way to document the behaviour that I expect and various assumptions along the way. If the behaviour changes, or if I do something that disregards the assumptions I made, I want the tests to fail.
I feel that I *should* be able to organize this in a literate way. If I want, I can even write human language documentation in the same place. The testing framework provides the same purpose that Web (or its equivalent) would -- it allows me to organize my discussion by design or by behaviour. The added benefit is that it is executable and so tells me if the production code is meeting my expectations. It also has the benefit of providing examples of how I expect the code to be used.
The problem that I tend to run into is that I have too much coupling between the implementation and the tests. As I refactor code, the discussion I make with the tests drifts and I end up having to refactor the tests considerably more than the production code. To combat this, I have made a practice of separating my unit tests from my larger scale behavioural tests, but I still end up with a lot of churn whenever I'm refactoring. Because of this churn, it's quite easy to lose track of where I'm discussing what issue and my ability to use the tests as literate documentation slowly disintegrates.
I've never actually done literate programming in the proper sense, so I wonder if people who do run into the same issues. I suppose it is possible they just try to avoid refactoring, which would be unfortunate.
I like to post as Anonymous Coward as much as the next guy (probably more so), but if you're going to post about your project and reply to questions in the thread, could you create an ID (if only for this discussion)? It would make it much, much easier to track what you are saying (and separate it from people who might try to impersonate you).
Anyway, thanks for the work on the graphics driver. This is an area that sorely needs developers. Every little bit helps. I hope your employer understands the difference between advancing the state of open source software and helping your competitor. I suspect you might find that you have stepped on a few toes, though. Soulskill didn't do you any favours in writing the summary, unfortunately :-(
I think you are over generalizing. Different approaches are good for different people. The summary says that the boy wants to learn on his own. He's probably fairly self motivated. When I was a kid I was the same. My father offered to teach me to program, but I wanted to do it myself. He threw me a textbook for a first year introductory university course and I read it cover to cover. I loved every page of it. I started out writing stupid text games, but I never really played them. I just liked programming. There are people (even kids) who don't want to be constrained by how someone else thinks they should learn.
C, Python, Ruby, Java, and even LISP based languages are all fine. The second language I learned was FORTH and it was fun. I might not throw them generative style C++ out of the gate, but for me learning every new style of programming was like an adventure. It really just depends on the person. Both syntactically and semantically programming languages are conceptually a lot simpler than human languages, but we throw our kids into foreign language study with abandon. We don't make them learn Esperanto because Spanish is too hard.
I don't disagree with your main thesis, but i don't think you could implement a system with Bitcoin the way you describe necessarily. Bitcoin relies on the idea that the compute power necessary to fake the block chain is more expensive than the benefit your receive for participating in creating the correct block chain. This is why people receive bitcoins for "mining". There has to be an incentive to mine that is higher than the cost of cheating. With Bitcoin as it stands now, the reward for solving the block chain is enough incentive. But if you vastly increase the amount/size of transactions, the incentive for cheating increases. This means you have to increase the reward for participation. Bitcoin's method for doing this is to have transaction fees. But I suspect that people will not be willing to pay enough fees, especially for small transactions.
I may be totally wrong (I haven't researched this at all), but my assumption about China subsidizing PV panels is that it's probably similar to what happened with RAM back in the day (I'm too old to remember when it happened -- get off my lawn!). Basically, Asian RAM manufacturer's undersold the American's due to subsidies. This caused all the American manufacturer's to go out of business. By the time the American's added duties to RAM, the cost of production in the large factories had fallen to the point where the Asian manufacturers no longer needed subsidies. With massively huge factories, they could be profitable at the previous low prices. The American's, on the other hand, would need to invest huge amounts of capital to build factories big enough to compete. And they never did.
In other words, the subsidies are there to build up production to the point where the the cost of entry to the market is too high for anyone else to come in.
IMHO, the effect of tariffs on PV panels will be similar to the effect of tariffs on RAM. It will raise prices in the US, but it won't protect the market.
I assume the OP means $1 for the cost of a solar panel which has a peak generation capacity of 1 watt. So in other words, the cost of a solar panel that has 1 kW of peak generation capacity is $1000 (I assume not including installation). That's what's normally meant by $x per watt. As you can imagine, solar panels do not have an operational cost, so it doesn't make sense to discuss the cost of solar power in terms of x kWh per month. After installation, it's free (well largely, anyway).
Normally you have a tie in with the local utility where you provide excess power that you generate during the day (when overall demand is high) and you take back some at night when you can't generate power. The local utility has to provide power up to the peak demand during the day. Having other producers supply power during that peak time allows them to scale back their equipment.
A solar panel rated at 1 kW of of peak generation will obviously not generate 24 kWh of electricity a day. It depends on location, how sunny it is, the season, what kind of installation you have, etc. But let's assume you can get 3 kWh of electricity from a 1 kW solar panel. You use about 12 kWh of electricity a day. So you would need 4 of these panels (or about $4000 at the OP's prices). You also have to pay for installation, so let's say $6K total. If you amortized that cost over the 20 year expected lifetime of the panels, you're talking about $46 per month at 7 percent interest, compounded monthly.
So, if the cost is correct, the OP's assertion seems to hold up. Where I live electricity is pretty near 40 cents per kWh (3 times what you pay) and we have a lot of sun. Solar panels are extremely popular these days. You can even buy them at the local hardware store. (Note that 3kWh per day is probably pretty optimistic for most locations, but you get the idea). As soon as I get my own roof, I will definitely be buying.
It's not so easy to change your name in Japan. First, your name is recorded in a family register. All citizens of Japan must be in a register. If you aren't you lose a lot of legal rights. When you get married, you *must* have the same name as your spouse, though either the man or the woman can change their name. When you change your name you must change it to your spouse's name. You can't make up a new one.
There are a few other times where you are allowed to change your name in the register, but you can't do it arbitrarily. I don't understand the rules. At the moment, I'm getting married and my fiance wants to use my (non-Japanese) name. My name is hard to pronounce in Japanese and I would like to use similar but different sounds from the usual transliteration. Even that looks like it will be impossible.
I haven't RTFA yet. I'm not sure what could have transpired to get the guy fired. Once the misunderstanding was cleared up, it shouldn't have been a problem. But once you loose your job in Japan, it is *very* difficult to get another one, dodgy name or not. His lack of ability to find a new job may be completely unrelated to the google searches.
Not sure you will see this, but I wanted to say that I looked at your code. I didn't spend nearly enough time on it to make a fair comment on it, but writing open source code is a great way to get feedback on your code. I definitely get the same feeling on my own project (http://jldrill.rubyforge.org/) with respect to "perfect is the enemy of new features". Often I need a feature and I simply don't have enough time to implement it well. Those kinds of short term and long term tradeoffs are tricky. The term "technical debt" is a popular one and describes the issue well, I think. Sometimes you can dip into debt, but if you don't repay it quickly enough, it can sink your project.
If there's one thing that I would suggest thinking about it's that there is almost certainly a sweet spot where attention to detail, while initially slower, improves productivity throughput overall. Things like writing unit tests can double your implementation time, but over the long run it may end up being significantly faster than not doing it (Actually, I will say that when done properly, this is almost certainly true). Additionally, there are subtle design issues that if you make a mistake, it can cost you a fair amount of time either through the resultant complex code, or though the need to refactor.
Training is really important. My little project is training for me. There is lots of crap code in there, either from failed ideas, experiments gone wrong, or just plain being too tired to do it correctly. But by working on it and being very attentive to what sucks I can make pretty good gains in my own ability to find appropriate designs quickly. You can't really do that on a work project because it is inappropriate to experiment that way. Looking at your code, I get the impression that you also get a lot of personal benefit from working on your project.
Thanks for the conversation!
Very interesting point of view. You are probably correct. I am probably projecting my own sense of values on RMS's thoughts. I will have to reflect on it a bit.
When you quote from such an article, it helps to add a link: http://mobile.osnews.com/printer.php?news_id=25724
The reason I say that is because, while I get your point, often RMS communicates in a rather blunt manner (IMHO anyway). It's not impossible for an astro-turfer to concoct an RMS-like quote that looks plausible but contains certain phrases that trigger "nutjob" knee-jerk reactions in people. Being able to point to the actual interview helps to show that it is authentic.
Unfortunately, I don't think he does himself any favors in this interview. Like you, I largely agree with him, but I wish that he would take some advice on effective methods of getting his message across. His use of the word "ethical" is troublesome. I think I understand what he means, but I guarantee that many people will interpret it as meaning that they are "unethical" if they don't run free software. I don't think that is what is intended (I might be wrong, I suppose). As a movement geared to *help* the user, using software that isn't free is unfortunate, but hardly unethical.
A free software community is powerful because instead of being consumers, the user is enabled to be a producer. If the software is not free, they are blocked from contributing (even if it is only to help themselves). If users choose software that isn't free because it is more capable, they get more capable software, but can't form a community of enabled users. They can't help themselves; they can help their friends and they can't be helped by their friends (or some random guy half way around the world who happens to have the same problem). Everything must come from one controlling entity. If they decide not to help (or decide to charge you ridiculous amounts of money), then you are screwed.
I suspect RMS thinks that people already understand this and simply says that free software is a matter of ethics to drive home his point. Unfortunately, I think many people completely miss the point and instead become insulted. It ends up having the opposite reaction that was intended.
For me the most important thing was having a presence. I had an IM client going all the time and was religious about updating my presence. If I was at the keyboard, it was obvious to anyone in the office. If I was away, it was obvious to everyone in the company. I was scrupulously honest about what I was doing. If I wanted to take a nap (which is easy to do from home), my status said, "Having a nap". Nobody cares what you do, but it can bother them if they don't know what it is. At work my manager can look over the cubicle wall and see that I'm at my desk. It can be uncomfortable if they can't do the same when teleconferencing.
A couple of other people mentioned IP phones. I agree with this. Video is great too (as long as you have clothes on). You want to make your home office as approachable as your work cubicle. People can look to see if you're there, they can wander in to ask a quick question, or just shoot the shit. Even small things like checking in your code frequently (every hour or so) makes people realize you are there and gives them an indication for what you are working on.
Sometimes you might think, "They don't *have* to know what I'm doing all the time." This is true, but the more different you are from the rest of the team, the harder it is for them to think of you as being on the team.
One more quick tip. In my office there were a couple of shared responsibilities like cleaning the kitchen, etc. I used to come in once every couple of weeks for a face to face. When I was there, I always took a turn on those shared responsibilities. I don't benefit from them, but its just another way to show that I'm part of the team. Small things like this made a big difference, I think.
I'd love to work from home again. I was incredibly productive. Right now I'm doing a different kind of job, but if I go back to programming (considering it) it would definitely be nice.
Coding dojos do something similar.
i've been coding for 8 years and as long as your code is maintainable, works, commented, and capable, you're doing a good job. also, for the love of god, don't hardcode your file paths or operating system. use a standard library, never do a system call. when you have do, error check it.
It's hard to comment based solely on what you have written because I've never seen your code. But I have to question the level to which you are aspiring. There is a huge gulf in quality between code that works and code that is minimal and obvious. You say "maintainable, works, commented and capable". Unfortunately, that could describe code that is barely acceptable all the way up to excellent. I don't really know what you mean, so this might be superfluous to you.
Code that works and is understandable is the minimum quality of code that I think is acceptable. But when you are designing (or refactoring) code, the decisions you make can have a large impact on the rest of the system. Because I read a lot of the original papers on design patterns, I tend to think of code as having a shape (a lot of the earlier descriptions used this kind of metaphor). Code that has an appropriate shape fits nicely with the rest of the code. It has a minimal complexity (i.e., the code is no more complex than the problem it is trying to describe). It also doesn't complicate other code that needs to talk to it.
On the other hand, code with a shape that is not appropriate does not fit in. It introduces complexity based on its shape alone (independent of the problem it is trying to solve). Code that needs to talk to it often has to do something extra, or carry around some extra data to make it work. This creates an inappropriate shape for this new code. When you have one thing that doesn't fit well, it can have a ripple effect that increases complexity all through the code. Not only that, but there can be a multiplying effect. Each work-around that you introduce to accommodate inappropriate code causes more and more complexity.
When I look at large software projects, most of the complexity usually comes from dealing with other code rather than solving the problem. The more code you have, the more complex your system becomes. Most software projects actually solve simple problems, but are still very, very complex. You might think that there is nothing you can do about this, but if you look at system libraries they often simplify your life. This seems opposite to the "more code = more complexity" argument. The difference is that these system libraries usually have an appropriate shape for what they are doing.
Your advice is generally sound. Learning to use appropriate idioms, learning to use appropriate reuse libraries, writing understandable, working code is the basis of programming. But there is another level beyond this. Choosing appropriate code shapes, keeping complexity to a minimum, understanding trade-offs of coupling and cohesion -- This is quite hard and requires a fair amount of practice. Excellent code is not just maintainable and documented, but also minimal and obvious. When other code interfaces with excellent code, it is easy to do so and it introduces a minimum of extra complexity.
IMHO, you should strive for this. If you think that you already accomplish this without thinking about it, then I invite you to look again. I suspect you may be overlooking something.
It's going to be nigh impossible to get anyone to review your work code, even though they should.
This is unfortunately all too true in most cases. Most organizations do not understand the benefit of rigorous code reviews. If they review code at all, they often only look to see if there are bugs, or if (usually fairly arbitrary) coding standards are followed. I've been lucky enough to work on a few teams with brutally honest reviews. It can be intimidating, but in the end it is incredibly useful for developing yourself. Things like pair programming can also be very useful in this regard.
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
For some reason, I often think about programming teams as if they were sports teams. The way most teams are run, you have a manager who knows little about the game you are trying to play and never watches a game. There are no coaches. You performance is loosely evaluated on whether or not your team wins games, but even then the manager usually tries to make it appear that the team won every game whether they did or not. When they try to get new players, they don't bother looking at the success of the player on their previous teams, or even watch them play. At most they set up some artificial 5 minute drill and evaluate that, but usually they base their decisions on a feel-good interview.
It's quite literally crazy IMHO. In the case of sports it is obvious that this isn't going to work. I'm not sure why it isn't obvious for programming teams.
When asked this question, I often think, "How do aspiring writers learn their craft?" People who study English read ridiculous numbers of books. This gives them a base to start from when they are writing.
Writing your own code is invaluable, but when you are just starting out it helps not only to contribute to open source projects, but also to read, read, read. I recommend going through some interesting projects and then forming an opinion about which ones have the best code. Don't just look at it superficially; try to form opinions on specific practices, idioms and designs. Then choose a project to work on and try to follow those ideas. From that point the feedback will be more valuable.
One of the things that Kent Beck said one time (possibly in an interview with Floss Weekly; I can't remember) was that his level really improved when he sat down and really thought about what he was doing. He just kept writing things over and over again until he could say exactly why he did everything. IIRC, he wrote down all his ideas and put it in a book on Smalltalk coding practices (which I haven't read yet...) I've been trying to do the same thing lately and it is really beneficial. Forming your own ideas and *then* getting feedback seems to be more productive than writing "just to make it work" and getting feedback.
Just be open minded when you think you have it all sorted out, but someone else thinks your ideas suck ;-)
Indeed. And it can lead to strange effects. The other day I was listening to some music on the radio (I forget what) where the singer started out with what was probably a quiet solo. After a while the orchestra swelled in the background. The singer's voice should have increased in volume to sing over top of the orchestra, but because the music was so heavily compressed, their voice actually diminished in volume while still being over top of the orchestra. The overall volume stayed the same.
I remember thinking, "Well, that's bizarre". It completely ruined the song. The soft, quiet part was annoyingly loud, with the singer's voice piercing my eardrums, and as the song built momentum and energy, the singer kept getting quieter and quieter.
You are missing an important word: he *reasonably* believed that he was selected because of his sexual orientation.
Just because someone believes they are being targeted would not be enough. You would have to give them some reason to believe they are being targeted.
It is true that it is possible to commit the crime without an intent to commit the crime. But this happens with other laws too. If I drive drunk, I may have no intent to kill someone, but if I do, I am still criminally at fault. People *do* have to be careful of their actions. You can't just do whatever you want to do. You have to think about the impact of your actions on others. If you don't, there are circumstances in which you will break the law. Specifically, if you cause harm to someone through your own negligence, even though you didn't intend to do it, you are still responsible.
In the case of preachers preaching against homosexuality, there are cases where it can cause harm. IANAL, but if someone were to say, "Homosexual's are evil and we must cast them from our society", I would suspect that they could be held criminally responsible if someone acted on that and started physically removing people from the community.
I think one of the areas where the law can be improved is that we tend to categorize things too much. Causing harm by targeting a population for their sexual orientation is illegal in many places. Causing harm by targeting slashdot readers may not carry the same penalty. There is probably some legal reason for this, but I don't really understand it.
I actually live in a country with no such laws (as far as I know). In Japan, while very uncommon, you can still see signs that forbid racially non-Japanese people from entering. I have been denied service twice at stores because I am not racially Japanese. I have very occasionally seen black vans drive by with megaphones shouting that foreigners must be made to leave. None of this is illegal as far as I know. Nothing in the law says you have to give service to every potential customer who walks up. Nothing in the law says that you can't say whatever you want to say (even through a loud megaphone, apparently -- that part is unfortunate at election times). It doesn't really bother me because it is incredibly rare. But if it happened all the time, even if no one person was breaking the law, it would be too much to bear. If *everyone* denied me service because I am white, I couldn't buy food. If *everyone* yelled at me and told me to get out because I was white, I could never relax.
It is specifically the targeting that is (and should be, IMHO) illegal. If you want to deny someone service, or if you want to tell them to get out of the country you should have to make an effort to show that you aren't targeting that person due to some class that they belong to. Targeting classes of people and causing harm to them also causes harm to society. Even if you didn't intend to target a class of people, but gave every reason to believe that you were, you still cause harm to society. This is why it is (and should be, IMHO) illegal.
I often get confused when people talk about "liberal" this and "conservative" that. From my non-American perspective, I see so little difference between the two that I can't bring myself to acknowledge that there is a substantive difference.
What the two "sides" tend to do is report an issue and exaggerate a piece of minutia, a nuance, or some abstract principle. They then blow that one thing up out of all proportion and highlight specifically how it is different from "other side". Finally, they leave the viewer with the impression that if everyone doesn't agree on this tiny bit of minutia, the whole world will go to hell in a hand basket. You *must* oppose the other side with all your heart.
They intentionally create a distinction in order to separate the two sides and give an illusion of choice.
But I would caution that the internet is far from free of that meme. If anything it can be worse if all you read is opinion. The one advantage is that it can sometimes be easier to trace down facts in order to create your own opinions. But verifying the facts is not trivial.
Similarly, if you are writing client code (or pretty much anything interactive), the program is spending the vast majority of its time waiting on the user. I have some Ruby code where I have to read in and parse some pretty big files. What I realized was that I could read the file into memory, quickly index the data and leave the majority of the parsing for later. The user isn't going to notice if I slow down giving results from 0.01s to 0.1 seconds when it takes them 2 seconds read the data.
Totally off topic, but it is very true that there are extremely capable people all over the world (not just India). These capable people will often work for much less than capable people in more "developed" countries. My experience has been that the problem with outsourcing to these capable people is that software development is a task requiring a lot of communication. Outsourcing parts of the process is almost always a disaster. You need to outsource the entire thing (middle management, QA, project management, documentation, etc, etc).
There is also one other problem. I've worked for a so-called "body shop" before in Canada. These consulting companies do not hire in the same way that an ordinary company would hire. They aren't looking to fill specific roles, but rather they want a hodge-podge of skills that will enable them to win contracts. Then, when they are trying to fill a contract, they don't put members on the team with the thought of creating success, but rather with the thought of keeping a range of skills available to win other contracts. The resultant teams can often be non-functional.
I think it is entirely possible to reduce development cost by moving development to a cheaper location. But you have to move lock, stock and barrel and hire permanent teams in the same way that you would do in your home country. Outsourcing only a part of your development to an agency in a far away, foreign country is pretty much a recipe for failure.
Drawings are not generally considered to be child pornography in Japan (the only place where I wouldn't be sure is if you were drawing an actual event).
The vast (really vast, vast, vast) majority of manga in Japan contains nothing that would be considered pornographic in Japan. There are certain magazines and books which contain pornography. Some of those contain drawings of children, though AFAICT the majority of those are of high school kids (I'm not an expert!). Some book stores will stock pornographic magazines, fewer of those stock the magazines that regularly have drawings of children. It's not terribly difficult to buy these things, but generally you have to go to a store which specializes in fringe interests. There is a large negative bias in the general population, from my experience.
Where you get into trouble is more mainstream manga/anime which has occasional nudity. Drawings of people bathing are relatively common (Kagome in Inuyasha, said to be 14 is naked in the first volume; Bulma in Dragon Ball, said to be 16 is naked in the first volume; etc). Japanese people think nothing of this, in general. Nakedness isn't unusual.
I hesitate to mention it (for fear that someone will misinterpret it), but in the onsen (hotsprings), fathers often bring their pre-teen daughters with them into the men's side. Nobody bats an eyelid. It's not a big deal. Drawings of the same thing, even if meant to be slightly titilating are not considered to be offensive. But I can imagine getting into huge amounts of trouble owning these drawings in Canada or the US.
What's incredibly scary for me is that it is easier than people might think to get caught by this. I live in Japan and my friend's daughter (who lives in Canada) asked if I could mail her a manga so that she could practice reading Japanese. Her favorite anime at the time was Inu Yasha.
No problem! I bought the manga, was all ready to mail it off when I thought, "Hey, I haven't read this for a while, maybe I'll just give it a read". Half way through the book, there's a picture of the main character (a 14 years old girl) taking a bath in the lake. Not an erotic scene IMHO, but I guarantee it meets the definition of child porn in Canada.
That's just what I need; to have a record for importing child porn to Canada.
Definitely tongue in cheek. I once went to the Canadian National Gallery and they had a modern art exhibit. One of the exhibits was a reel-to-reel tape recording of a waterfall, cut up into pieces and stuffed in water bottles. I thought it was a clever idea, but I didn't consider it to be particularly good from an art perspective.
On the other hand they had another exhibit where the artist wrote a set of requirements for what he wanted on index cards. He then gave the index cards to his students and asked them to collaborate to create the art. The result was awful. There was even a letter by the artist describing how disappointed he was in the resultant piece. He said that before the experiment he had a high opinion of his students and that their inability to use common sense to create a piece of artwork based on his instructions made him question that.
I think a lot of people would look at that exhibit and think, "Meh...". For me, I thought it was absolutely brilliant. This exhibit captured the essense of the problem people face when making collaborative projects like software. It was incredible.
Art often requires the viewer to have a certain perspective before it is effective. A set of colorful horizontal lines is completely meaningless to me and "bad art". I can actually understand that it is "brilliant" to someone else who has a different perspective.
A lot of the current research points at reading as being a very effective means of language acquisition. You have to read a lot, though (more than most people would do -- 2-4 million words a year). Choosing books at an appropriate level is also difficult. People almost universally choose books at a level that is far too high. People who have learned a language up to the level of a 5 year old are considered "advanced" speakers (6,000 words of vocabulary and all the basic grammar). They are often dismayed when they can't even read a book aimed at elementary school children (which is, by definition, far above their level). I'm lucky in that Japan has a vibrant comic book culture and I can find a huge number of level appropriate, conversationally oriented books to read. Unfortunately a lot of language learners consider doing these kinds of things somehow beneath them and childish.
I appreciate you having read all my long typing :-) I think you are correct that I need to find a more appropriate word where I'm using "easy". I'll have to think about it. I just want to reiterate that you *can* learn another language to a very high level of fluency. Just keep in mind that most of the language learning educational system is stuck behind ancient and largly inefficient methods of language acquisition. I teach English to Japanese kids as my day job. My colleagues are all fluent in English. I often ask them if the method of learning they teach was effective for them in acquiring English. Without exception, they say that their success in learning English came by a completely different method. Don't be afraid to throw the textbook out (or rather, unless you are finding it is working for you, please throw it out -- it will only slow you down). All you require to learn a language is that you understand what you are hearing/reading, that you get enough volume of input to learn at a reasonable rate, and that you get enough repetition at the correct times to retain what you've learned. I have found that a dictionary, grammar dictionary and a huge pile of books is enough. There are, of course, other things you need to do for pronunciation, etc (I do karaoke in Japanese, watch TV, etc, etc), but you are really only limited by your imagination.