Agreed. All it did was generate Javascript for you. In the long run, I think that's unhelpful.
Of course, where Rails probably did help you was in making the request handling really easy, which is what it's good at. But ajax is all about the client-side, and Rails is all about the server side. Both are necessary, but they are not the same thing.
Figure out where all the APOTAS* are and learn how to meet** them. Spending a summer doing that will be far more rewarding than any crappy business you can put together in 3 months.
* APOTAS == attractive people of the appropriate sex:)
I think Apple really wishes customers would simply go out (or online) and procure a bigger hard drive or more RAM themselves.
If that's true, I wonder why the standard amount of RAM on all Macs is so rediculously low. If they threw in more RAM, perhaps fewer people would custom configure their computers.
Yeah, I'd accept non-XP things if I was hiring a firm, but since the OP said he was going to max his credit cards to pay for development, I was assuming he was going to hire some programmers, not a firm.
But either way, I almost agree with you. I'd hire them based on their demonstrated ability to get useful software out the door iteratively, without lots of bugs piled up at the end, and without a mess of code that would take forever to fix if I were to continue development, then hope they keep doing whatever they'd been doing.
Hire a couple people who have experience with extreme programming (XP). They'll deliver exactly what you want, without bugs*, with a release every week.
You tell them the most important things to do, and they'll do them in order of your priority (not some made-up technical priority). They won't do other things that they think are nice, just the parts that you ask them for. Hopefully, you'll ask them for only what is needed for your demos.
The weekly releases are key; you can see exactly what's happening. You don't have to wait 6 months to find out that the program doesn't really work, or doesn't do what you want it to do. You'll also quickly get a usable program that does the few things that you need to demo. If at that point you realize that your product idea wasn't so hot after all, you've just saved a lot of money over what you would have spent if you hired a team that wanted to spend all kinds of time creating a flowery design and building infrastructure.
As far as hiring XP types, try to find a local XP person who is well-respected and ask him or her for some leads. Maybe get a technical friend to help interview the programmers. But be sure to hire people who have experience working this way. You don't want to pay them to learn how do release software incrementally.
(*By "without bugs", I mean "without known bugs". Lots of people write software and leave a lot of bugs in until the end. That hurts demos. XP people will fix buggy code as soon as they see it. And they'll write automated tests to make sure that bug never shows up again.)
Who, other than geeks, is going to remember those commands?
It's so much easier to do it the Mac way: download it and drag it into the Applications folder. Even easier would be a program that lists all the available applications instead of forcing the user to find them on the web.
If you have to work late on the computer, tell your roommate that you're going to be up for a while making noise. He'll grumble a bit, get up, and walk down to the girls' side of the floor. He'll knock on a random door which will be opened by a beautiful blonde.
He'll say, "My roommate is making noise, can I sleep here?" She'll let him in and he'll see that her hot roommate is totally naked. Five seconds later, the three of them will be having sex for hours and hours (with the lights on at full intensity of course).
You'll be working on your geeky project the whole time, constantly adjusting the tape on your glasses and making nerdy expressions.
I wonder if someone could build a device that sits between the computer/console and the monitor/TV that cleans the video signal so it's not a hazard.
Let's say that the cause of the problems is a change in brightness of x% ocurring between a and b Hz. Maybe the device could sense that and reduce the brightness, or even drop the framerate to below a or something.
Maybe people don't know the exact parameters that cause a seizure, or maybe it would be too expensive... but maybe it would work.
Nobody buys a Mac because it is faster or cheaper than a PC. Apple says that Macs are faster. Others dispute that. Others dispute the disputers.
It doesn't matter. You buy a Mac if you like Macs. I personally enjoy using Mac OS X far more than using Windows. Everyone I know who uses Macs love Macs. Nobody I know who uses PCs love PCs, they just tolerate them. But you need to decide for yourself.
Now, you asked about Java performance on the Mac. It's fine. I recently switched from doing Java development on a PC to a Mac, and the Mac was faster. It was a faster machine (a dual 1.25 GHz G4 vs a single 1.6 GHz Athlon), so what this proves is that the Java performance on the Mac isn't totally horrible (otherwise the faster machine would have been slower at Java).
One thing to consider is that Apple, not Sun, is in charge of making the JVM. Apple is always a bit behind. They just recently released 1.4.2, for example.
And I would disagree with the people who recommend XCode. It's a nice IDE, but if you're doing pure Java, then you're better off using a smart IDE like IDEA or Eclipse that can do refactoring and smart code completion. IDEA and Eclipse both run fine on the Mac, though they look and feel a bit weird (IDEA has been getting much better recently; check out the version 4.0 release candidate instead of the currently-shipping 3.0 release).
Finally, if you do decide to get the Mac, and you've never bought a Mac before, here are some tips: Apple (like all manufacturers) charges a lot for extras so you might want to consider buying extra RAM elsewhere, and fixing a Mac can be expensive so I would recommend Apple's extended warranty, especially on a laptop.
Instead of treating the leeches as enemies, treat them as friends.
Perhaps you could have a special section of the site just for leeches. Explain your problems: you have too many people downloading everything.
Ask for solutions. Maybe they'd all be happy with BitTorrent. Maybe they could help set up mirrors. Maybe they'd voluntarily restrict their leeching to lower-traffic times like the middle of the night. If you do some kind of throttling, maybe they'd rather buy a CD containing all your stuff than wait a couple days for everything to download (okay, probably not).
My initial impression of XP (I haven't tried it but had it explained to me) is that it takes a lot of the fun and programmer-as-artist aspect out of software development.
It doesn't take the fun out. It's all about making sure the developers develop exactly what the customer wants. The customer is the person paying for the project (or a duly appointed representative). I'm not sure who the customer would be on a distributed OSS project. Perhaps that role can't exist, and therefore perhaps XP is unsuited to such projects.
I can take your "programmer-as-artist" comment two ways. The first is that programming is an art, in that you can come up with creative solutions to problems and you can create a working system from nothing more than (sometimes vague) requirements. You can still do this with XP. In fact, it should be easier.
The othe way one can take "programmer-as-artist" is that the programmer not only decides how to do something, but what to do. In XP, those two roles are separated. However, a programmer could also be the customer. That would make sense on hobby projects and other projects where nobody is paying for the development to be done. If someone is paying for the development to be done, than that person must make quite sure that the programmer really knows what the program should do and isn't wasting time throwing in things that just might be cool.
Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
You say this as if it's a bad thing. It's a great thing. The average programmer is, by definition, average. (Okay, math geeks, you can chime in now about how it's only the mean programmer who's average, or whatever.)
Pair programming works on certain problems, where one of the two has asked for help, but otherwise it's counterproductive and lets both parties get very annoyed with each other.
Perhaps it was counterproductive for you, but I really like it and lots of other people do too.
Some of the other rules in the article are nice in theory, but not really practical in real life. For example: customers aren't always available, and often don't want to be either.
I would not want to work on a piece of software where the person paying for it refused to be around to help me figure out what it's supposed to do! If I just have to guess, then I'm going to be wrong and nobody's going to be happy.
Involving the customer too much usually ends up in them wanting something other than what they originally agreed to, but within the same time frame and for the same price
EXACTLY!! You've perfectly described the whole reason for XP. There's a reason XP's motto is "embrace change". Customers very often change their minds. You can say, "I know you're paying me, but too bad, you said you wanted X and that's what you're going to get." How does that help anyone? I like to say, "Sure I can change it."
(and then they get upset when they can't have it).
But they can have it! They are the ones who are paying for the software, and XP is all about letting them get what they want.
I think that some of the XP practices can still be very helpful though. Test-driven development and short iterations seem like they'd work with a distributed team. Same with refactoring. Collective code ownership and continuous integration might work well too.
But certainly, if you did all those things it still wouldn't be XP without the pair programming and the on-site customer. But that's okay.
Are you sure you need a "database"? Can't your store your data in a text file? Or a few text files? Maybe an XML file if you've got a lot of data? Or maybe serialize your objects (i.e., write them all to disk)?
A lot of people here keep suggesting RDBMSs and SQL this and SQL that. I've been using relational databases professionally for about ten years. They are certainly powerful, but I think they're overkill for most applications.
My advice is to start with a flat file, and when your app demands something more, go to a few files. When your app demands even more, think about serialization or XML or something. If you need more power, then go to something like Berkeley DB or some other simple DB. Only when you really really really need something complex should you consider a RDBMS.
I ask because I am a student, looking to get a tech job in the future....
Study what you enjoy. Get a internship or co-op job doing whatever you want your career to be.
Here's an interview quesion I would ask: "Why did you decide to get XYZ degree?" If the answer is, "to get a good job", then I might reject the person because I'd much rather hire people who are passionate about what they are doing.
When a company receives a bick stack of applications for a tech job, they may cull the stack by looking at certifications.
True, but it would be even easier to get the job if you can avoid being lumped in with everyone else.
Most jobs (so I've heard) go to "friends of friends" or "colleagues of colleagues". So go get yourself noticed.
If you belong to a church, maybe you can help them out with any technical needs, and maybe someone there will remember you next time they're looking for techincal people.
Or go fix up a school's computers. Make sure to show up on any award night where the school recognizes all the hard work you've put in. Maybe someone else will notice and offer you a job. Or maybe that article about you in the local paper ("Local man spends summer fixing up school's computers for free") will get you noticed (especially if your phone number or website is listed in the article).
There are probably lots more ways to do it... none of them easy, but probably a lot more effective than hoping to have one more acronym than every other resume in the stack.
Computer science has nothing to do with computer networking. I don't see a CS degree improving anyone's career in networking. There are other degrees like Information Systems that might be more applicable.
(Though IMHO, you should never think of a university degree as career training. It will do a lot for you, but it won't give you any critical career experience. Nor is it designed to.)
If not then get someone who is to do this job for you.
Court reporters do this kind of thing for a living and some (all?) are contract workers. They can do it in real time and would probably be quite happy to be able to do it all at home rather than in a deposition room or court room. Oh, and their accuracy would be a lot higher than if you did it yourself without checking or if you hired a student to do it.
I also don't like...the menu bar being "out of my way" so I can't access it...
It's not out of your way. In fact, it's at the top of the screen to make its effective area huge, so that it's easier to get to.
On all other OSes I've seen, the menu bar is as wide as a window and about 20 pixels tall.
On the Mac, the menu bar is as wide as the screen, and infinite pixels tall. (Because you just shoot your mouse up and it always stops at the top edge of the menu bar.) This makes accessing the menu bar much much faster. They did real tests to provie it, too.
Apple fans may fall in love with the cube on sight.
Although I am not a fan of using apple systems, apple has really changed the way computer manufacturers design computer systems.
This cube looks like something a cheap apple cousin might design.:)
what is funnny is that this dude thinks looks are all that matter.
Uh, the article said that Apple users would like the way it looks. This guy was saying that Apple users would realize that this thing looks like crap.
Slashdot Mirror
Agreed. All it did was generate Javascript for you. In the long run, I think that's unhelpful.
Of course, where Rails probably did help you was in making the request handling really easy, which is what it's good at. But ajax is all about the client-side, and Rails is all about the server side. Both are necessary, but they are not the same thing.
So to clear up a common misconception: Rails is not at all related to ajax, and it doesn't really help you write ajax-y web applications.
Figure out where all the APOTAS* are and learn how to meet** them. Spending a summer doing that will be far more rewarding than any crappy business you can put together in 3 months.
:)
:) :)
* APOTAS == attractive people of the appropriate sex
** meet == screw
If that's true, I wonder why the standard amount of RAM on all Macs is so rediculously low. If they threw in more RAM, perhaps fewer people would custom configure their computers.
Yeah, I'd accept non-XP things if I was hiring a firm, but since the OP said he was going to max his credit cards to pay for development, I was assuming he was going to hire some programmers, not a firm.
But either way, I almost agree with you. I'd hire them based on their demonstrated ability to get useful software out the door iteratively, without lots of bugs piled up at the end, and without a mess of code that would take forever to fix if I were to continue development, then hope they keep doing whatever they'd been doing.
Here's what I would do:
Hire a couple people who have experience with extreme programming (XP). They'll deliver exactly what you want, without bugs*, with a release every week.
You tell them the most important things to do, and they'll do them in order of your priority (not some made-up technical priority). They won't do other things that they think are nice, just the parts that you ask them for. Hopefully, you'll ask them for only what is needed for your demos.
The weekly releases are key; you can see exactly what's happening. You don't have to wait 6 months to find out that the program doesn't really work, or doesn't do what you want it to do. You'll also quickly get a usable program that does the few things that you need to demo. If at that point you realize that your product idea wasn't so hot after all, you've just saved a lot of money over what you would have spent if you hired a team that wanted to spend all kinds of time creating a flowery design and building infrastructure.
As far as hiring XP types, try to find a local XP person who is well-respected and ask him or her for some leads. Maybe get a technical friend to help interview the programmers. But be sure to hire people who have experience working this way. You don't want to pay them to learn how do release software incrementally.
(*By "without bugs", I mean "without known bugs". Lots of people write software and leave a lot of bugs in until the end. That hurts demos. XP people will fix buggy code as soon as they see it. And they'll write automated tests to make sure that bug never shows up again.)
Don't forget the UPS. You wouldn't want the power to go out in your house and lose all your work, would you?
(Oh, sorry, this is Slashdot. I meant, "...and loose all you're work...".)
I think you've proved the OP's point.
Who, other than geeks, is going to remember those commands?
It's so much easier to do it the Mac way: download it and drag it into the Applications folder. Even easier would be a program that lists all the available applications instead of forcing the user to find them on the web.
Easy solution:
If you have to work late on the computer, tell your roommate that you're going to be up for a while making noise. He'll grumble a bit, get up, and walk down to the girls' side of the floor. He'll knock on a random door which will be opened by a beautiful blonde.
He'll say, "My roommate is making noise, can I sleep here?" She'll let him in and he'll see that her hot roommate is totally naked. Five seconds later, the three of them will be having sex for hours and hours (with the lights on at full intensity of course).
You'll be working on your geeky project the whole time, constantly adjusting the tape on your glasses and making nerdy expressions.
Or maybe I've been watching too much porn...
Van Flips, Spills 350 Hard Disks Full of Porn
Cops Have A "Hard" Time Cleaning It Up
Let's say that the cause of the problems is a change in brightness of x% ocurring between a and b Hz. Maybe the device could sense that and reduce the brightness, or even drop the framerate to below a or something.
Maybe people don't know the exact parameters that cause a seizure, or maybe it would be too expensive... but maybe it would work.
It doesn't matter. You buy a Mac if you like Macs. I personally enjoy using Mac OS X far more than using Windows. Everyone I know who uses Macs love Macs. Nobody I know who uses PCs love PCs, they just tolerate them. But you need to decide for yourself.
Now, you asked about Java performance on the Mac. It's fine. I recently switched from doing Java development on a PC to a Mac, and the Mac was faster. It was a faster machine (a dual 1.25 GHz G4 vs a single 1.6 GHz Athlon), so what this proves is that the Java performance on the Mac isn't totally horrible (otherwise the faster machine would have been slower at Java).
One thing to consider is that Apple, not Sun, is in charge of making the JVM. Apple is always a bit behind. They just recently released 1.4.2, for example.
And I would disagree with the people who recommend XCode. It's a nice IDE, but if you're doing pure Java, then you're better off using a smart IDE like IDEA or Eclipse that can do refactoring and smart code completion. IDEA and Eclipse both run fine on the Mac, though they look and feel a bit weird (IDEA has been getting much better recently; check out the version 4.0 release candidate instead of the currently-shipping 3.0 release).
Finally, if you do decide to get the Mac, and you've never bought a Mac before, here are some tips: Apple (like all manufacturers) charges a lot for extras so you might want to consider buying extra RAM elsewhere, and fixing a Mac can be expensive so I would recommend Apple's extended warranty, especially on a laptop.
Instead of treating the leeches as enemies, treat them as friends.
Perhaps you could have a special section of the site just for leeches. Explain your problems: you have too many people downloading everything.
Ask for solutions. Maybe they'd all be happy with BitTorrent. Maybe they could help set up mirrors. Maybe they'd voluntarily restrict their leeching to lower-traffic times like the middle of the night. If you do some kind of throttling, maybe they'd rather buy a CD containing all your stuff than wait a couple days for everything to download (okay, probably not).
It doesn't take the fun out. It's all about making sure the developers develop exactly what the customer wants. The customer is the person paying for the project (or a duly appointed representative). I'm not sure who the customer would be on a distributed OSS project. Perhaps that role can't exist, and therefore perhaps XP is unsuited to such projects.
I can take your "programmer-as-artist" comment two ways. The first is that programming is an art, in that you can come up with creative solutions to problems and you can create a working system from nothing more than (sometimes vague) requirements. You can still do this with XP. In fact, it should be easier.
The othe way one can take "programmer-as-artist" is that the programmer not only decides how to do something, but what to do. In XP, those two roles are separated. However, a programmer could also be the customer. That would make sense on hobby projects and other projects where nobody is paying for the development to be done. If someone is paying for the development to be done, than that person must make quite sure that the programmer really knows what the program should do and isn't wasting time throwing in things that just might be cool.
Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
You say this as if it's a bad thing. It's a great thing. The average programmer is, by definition, average. (Okay, math geeks, you can chime in now about how it's only the mean programmer who's average, or whatever.)
Perhaps it was counterproductive for you, but I really like it and lots of other people do too.
Some of the other rules in the article are nice in theory, but not really practical in real life. For example: customers aren't always available, and often don't want to be either.
I would not want to work on a piece of software where the person paying for it refused to be around to help me figure out what it's supposed to do! If I just have to guess, then I'm going to be wrong and nobody's going to be happy.
Involving the customer too much usually ends up in them wanting something other than what they originally agreed to, but within the same time frame and for the same price
EXACTLY!! You've perfectly described the whole reason for XP. There's a reason XP's motto is "embrace change". Customers very often change their minds. You can say, "I know you're paying me, but too bad, you said you wanted X and that's what you're going to get." How does that help anyone? I like to say, "Sure I can change it."
(and then they get upset when they can't have it).
But they can have it! They are the ones who are paying for the software, and XP is all about letting them get what they want.
I completely agree.
I think that some of the XP practices can still be very helpful though. Test-driven development and short iterations seem like they'd work with a distributed team. Same with refactoring. Collective code ownership and continuous integration might work well too.
But certainly, if you did all those things it still wouldn't be XP without the pair programming and the on-site customer. But that's okay.
Are you sure you need a "database"? Can't your store your data in a text file? Or a few text files? Maybe an XML file if you've got a lot of data? Or maybe serialize your objects (i.e., write them all to disk)?
A lot of people here keep suggesting RDBMSs and SQL this and SQL that. I've been using relational databases professionally for about ten years. They are certainly powerful, but I think they're overkill for most applications.
My advice is to start with a flat file, and when your app demands something more, go to a few files. When your app demands even more, think about serialization or XML or something. If you need more power, then go to something like Berkeley DB or some other simple DB. Only when you really really really need something complex should you consider a RDBMS.
Study what you enjoy. Get a internship or co-op job doing whatever you want your career to be.
Here's an interview quesion I would ask: "Why did you decide to get XYZ degree?" If the answer is, "to get a good job", then I might reject the person because I'd much rather hire people who are passionate about what they are doing.
True, but it would be even easier to get the job if you can avoid being lumped in with everyone else.
Most jobs (so I've heard) go to "friends of friends" or "colleagues of colleagues". So go get yourself noticed.
If you belong to a church, maybe you can help them out with any technical needs, and maybe someone there will remember you next time they're looking for techincal people.
Or go fix up a school's computers. Make sure to show up on any award night where the school recognizes all the hard work you've put in. Maybe someone else will notice and offer you a job. Or maybe that article about you in the local paper ("Local man spends summer fixing up school's computers for free") will get you noticed (especially if your phone number or website is listed in the article).
There are probably lots more ways to do it... none of them easy, but probably a lot more effective than hoping to have one more acronym than every other resume in the stack.
Computer science has nothing to do with computer networking. I don't see a CS degree improving anyone's career in networking. There are other degrees like Information Systems that might be more applicable.
(Though IMHO, you should never think of a university degree as career training. It will do a lot for you, but it won't give you any critical career experience. Nor is it designed to.)
Court reporters do this kind of thing for a living and some (all?) are contract workers. They can do it in real time and would probably be quite happy to be able to do it all at home rather than in a deposition room or court room. Oh, and their accuracy would be a lot higher than if you did it yourself without checking or if you hired a student to do it.
Though a tech solution would be cool...
But that's okay, because it's obvious that John Mellencamp stole all his stuff from Johnny Cougar anyway.
1. Imagine
2. Define
3. Architect
4. Develop
5. Deliver
I would be wary of teaching stone-age software design concepts to impressionable young minds...
It's not out of your way. In fact, it's at the top of the screen to make its effective area huge, so that it's easier to get to.
On all other OSes I've seen, the menu bar is as wide as a window and about 20 pixels tall.
On the Mac, the menu bar is as wide as the screen, and infinite pixels tall. (Because you just shoot your mouse up and it always stops at the top edge of the menu bar.) This makes accessing the menu bar much much faster. They did real tests to provie it, too.
Uh, the article said that Apple users would like the way it looks. This guy was saying that Apple users would realize that this thing looks like crap.