skidooer

You certainly make a valid point, but I must add:

Rails is a fast moving target because they are always looking for new ways to save you time. As I mentioned in a previous post, the Rails 1.0 API is painful compared to the current generation. You are saving massive amounts of time during development because the project has evolved so far.

Spending a few minutes patching a framework bug once every five years pales in comparison to the gains you are seeing in development time.

To each their own, but I'd rather have a framework that is better than have a framework that knows it could be better, but won't make the changes because it might break some several year old app.

I too was talking about the Rails framework. It's actually a really nice read. I've fixed a couple of bugs in it myself.

The thing to remember is that each major release of Rails is fairly well tested. The number of actual bugs you are going to encounter are low. The investment in fixing them is therefore going to be low, should you actually encounter any to begin with.

The Rails codebase is simply an extension of your own codebase. While it is not fun to fix bugs in any capacity, there is no reason to fear fixing bugs in third party code. It is no worse than fixing your own, which also costs a lot of money.

I've been using Rails since around the 0.8 release timeframe. I have seen many major changes along the way. They have all been positive improvements to my workflow and the theoretical issues you describe have never been real issues. I still have one app chugging away on Rails 1.1 and it works just fine. The only problem it has is that it is not nearly as fun to maintain because it doesn't have all the newer major improvements. It would be a sad day if we had to go back to, or were still using, the 1.0 API. The Rails people are doing the right thing.

> When bugs are discovered in the old version most likely they will not be fixed because everybody has already moved on.

Is this a real problem? If you encounter a bug in an older version of Rails, why not just fix it and carry on as usual? Fixing bugs is part of the job of being a developer. If you are afraid to fix bugs, your application isn't going to last long no matter what language, framework, or platform you choose.

I'm not sure that it is true. There is no data I have been able to find that supports the claim and there has been several articles on HN lately that strongly support the opposite view.

The best I have been able to find on the matter is one study that shows a loose correlation between those who have a formal education tend to have a higher income. Which, of course, says nothing about the effect of the education on the resulting job.

The article states that only the filename needs to be passed for CSS url() resources. However, using that method, there appears to be no means to append the MD5 to the precompiled asset filename while in production. The result is an unnecessary trip to the application to generate the asset, bypassing the compiled assets completely.

I believe the preferred method it is to generate your CSS with ERB, using the asset_path method. Though hopefully someone can correct me if I'm wrong.

Colleges transitioned from being a place of higher learning to a place "where dreams come true" several years ago. Preparing your students to build the next Angry Birds or Facebook instead of reimplementing a search algorithm that has been implemented a million times before is much more in line with the goals of both parties. A strong foundation in CS is not necessary, or even important, when your goal is financial success.

I do agree that the fundamentals are very important for those who are interested in pure academic pursuits. It is very unfortunate that college has become the goto place to get a job, not a place to learn. But the truth of the matter is that the vast majority are only in class because they are looking for future wealth. Colleges, being businesses, will naturally tend towards catering to their customers.

The good news is that with the proliferation of the internet, academics can now learn about CS fundamentals even if the formal CS programs go into decline. Of course it is not too late to fix the education system, we just have to get past the idea that college equals job and return school back to its roots of a place to research and study.

I admittedly haven't spent much time with Rails 3.1, but isn't that what rake assets:precompile is for?

Automatic compilation of coffee scripts is nice in development, but not overhead you want to add for production anyway.

The Web 2.0 movement was about opening up the data in computer consumable formats and APIs. Nothing more.

While exchanging data over the internet is obviously nothing new, having large organizations provide easy programmable access to their private databases was somewhat revolutionary. The whole App craze was born out of being able to create new interfaces to existing services, thanks to Web 2.0.

Web 2.0 was nothing new from a technical perspective, but it was a revolutionary social shift.

> how come not all great programmers are great writers?

I imagine most programmers are great writers from a structural point of view. The rest is emotion. Programmers know how to appeal to machines, but often are not able to connect with people in the same way; something that extends beyond writing, if stereotypes are any indication.

The type system exists, but when working with the Objective half of the language, it is mostly meaningless, at least from a developer's point of view. With the C parts removed, you could replace every type definition with id and your program would run just fine.

The article says that MacRuby is bundled with Lion as a private framework. Surely they wouldn't bundle it if they weren't using it? And being a private framework, it is not there for the benefit of third-party developers.

I may be misunderstanding you, but:

When you remove the C bits, Objective-C and Ruby use the same type system, conceptually speaking. They are both descendant from Smalltalk; the main feature differences really come down to the syntax alone.

I really like the idea of a higher level Objective-C-based language, I just don't necessarily see the business appeal of creating and maintaining a brand new language that only brings a more familiar, to Objective-C developers at least, syntax. Especially given the amount of effort Apple has been putting into MacRuby.

Ruby essentially is Objective-C without the C.

If Apple was looking for a language that moved away from the low level C, what benefit would an "Objective" language bring over MacRuby, which is already using the native Objective-C system frameworks?

I estimate 90% of the people who use my app have pirated it. That is based on server communication with the app that would not be easily duplicated by outside sources like Google crawlers. There is some margin of error: Each purchased copy is able to be installed on up to five devices, for example. But I find it to be still fairly telling.

What is more interesting is that I noticed a dramatic drop in sales when it started to be distributed on the pirate websites. I'm not quite sure what to make of that, but it does give some indication that piracy did affect me.

For what it is worth, my app appeals to the geek crowd. From the data I have been able to acquire, I would say the majority of my users, including legitimate ones, are running jailbroken devices. That may help skew the piracy rates towards the higher end.

Ultimately, I'm not worried about it. I wasn't banking my livelihood on the success of the app. It has made enough money to recoup my time investment, which is an added bonus. I do feel for the users who did pay for my app, however. I do feel that piracy has prevented me from spending more time making the product better for them. That is the real unfortunate side.

Seems like a better way to put it is: Design first, then develop. Which, in my experience, is a good idea whether you are responsible for the design or not.

If you have no data structures or other programming limitations to work with, you can focus on perfecting the interface and then worry about making it happen. If you already have the program written, it is natural to want to take the easy way out and just slap up a form that matches the code.

An aside, being someone who enjoys playing both roles, I find the design phase goes a long way to improving the structure of my application because I have time to get a better understanding of the requirements, program flow, etc. Every element I draw automatically turns into code in my head, thinking about how it is going to be implemented as best as possible. The program is already written long before I ever touch a text editor.

Furthermore, programming is design. A programmer's job is to write code that is not only functional, but code that is visually appealing. Visual appeal is the factor that makes code maintainable or not. It is basic human nature to want to work on pretty code and reject ugly code. As such, it is wrong to say programmers do not have artistic talent. They exercise it each and every day. The only thing many programmers lack is practise in designing visual interfaces.

Given all of that, I find it very unfortunate that we try to separate the design and development jobs. I understand the business appeal of trying to do the job twice as quickly with two people, but from a fundamental point of view, the separation only goes to hinder the quality of our software, in my opinion.

> One likely works on projects as part of employment. One may work on projects outside of employment.

I guess my confusion in your original response comes from the notion in my belief that all work is employment. Although I do believe I have a little bit of a better understanding of where you are coming from now.

With that said, even when I'm hacking away for fun on purely personal projects, I still consider that an act under the umbrella of my business – which does happens to be a corporation in my case, but it need not be. If the project turns into something that is marketable, it will be sold under my business. That also adds to the confusion of where to draw the line.

Ultimately, I strongly believe the employer is going to be interested in what you have been doing no matter what the circumstances. If it is interesting and applicable to the job, it is not going to matter who commissioned the work or how much you were paid to do it and it is certainly going to look a lot better than a job at McDonalds.

On a resume, you would state that you worked under "Your Name", and you can elaborate by describing "A project" to stick with generally accepted formatting rules, but in day to day dialog I have to disagree with your assertions.

A project is exactly how I describe what I am working on, whether I am being paid by someone else or if I am paying myself – someone is always paying for your time, even if that someone is you. I'm sure even you would agree that my day job projects are employment.

I believe my question still remains. If not all projects are employment, when does working on a project become employment? What criteria need to be met?

> just that they shouldn't attempt to make a project look like employment if it isn't.

What is the difference? I am having a little trouble drawing the distinction.

- If a self-funded project is not employment, does it become employment when someone else funds it?

- If you self fund a project and you are able to sell the result of your project, does that make the work leading up to the sale employment? What if you are never able to make a sale?

- Do you have to be just another cog in the wheel of a big business to be considered employed?

- Why is searching for a job not the same as searching for new customers (i.e. sales, a real profession)?

As far as I can tell, they are all exactly the same. Where does the line get drawn?

CEOs are often hired into the position, so there may be some educational bias. What would be interesting by this discussion is how many of those CEOs were founders of the company?

Oftentimes preconceived notions about tech will cloud your vision on implementation. If you are aware of a certain challenge, you will, more often than not, change your design to simplify the challenge. Someone without the experience will not be bound by those limitations and can always figure out how to do it later.

When we look to high profile businessmen, more often then not they do not have the education behind them. Nothing wrong with getting some training, but I'm not sure it is beneficial when it comes to business. There is no evidence that supports it.

Unlikely, perhaps. But definitely possible from a technical perspective.

The key doesn't have to be stored on the server. It can be on a private computer that is not connected to any network at all. Still vulnerable, but much less so.

There's a show in Canada named Til Debt Do Us Part that has a similar premise, except they usually visit higher class households (usually $100K/year+ earners) who still have managed to rack up tens to hundreds of thousands of dollars worth of consumer debt.

While karma is meaningless, I appreciate your reply instead of just voting me down. I was wondering what was wrong with my post and appreciate any feedback that can help me provide better comments in the future.

In my experience, those who are passionate about a topic want to learn about all of the topics surrounding that topic. If you like to drive, you're probably going to want to know what makes a car tick and even get your hands dirty. I know that's not true of everyone, but generally speaking, I think it is.

You don't have to be passionate about driving to be a good driver. However, given the choice, why wouldn't you want to hire the guy who lives and breaths cars if they are also an excellent driver? Their additional skills will not hurt to have around, even if they are not directly applicable to the job at hand.

If you are at all interested in the job, you're going to apply no matter what the ad says is required. However, the long list of requirements gives you some insight into what the company does. Asking for a C++ programmer could mean anything, but if you also need MySQL experience, you've got a good indicator that you're going to be writing code that interfaces with a database. This helps you weed out the candidates offering jobs you may not be at all interested in.

Talent is subjective and fairly assessing one's own abilities is impossible, but I have been employed in both programming and design jobs and have received a lot of positive feedback in both domains. Given that, I think the thought processes behind each are very similar:

In programming, design is just as important as logic. Code not only needs to be functional, but it also needs to look good. A visually attractive codebase is much more maintainable due to the basic human response to beauty.

In design, logic is also just as important. When designing an interface, for example, you are constantly solving problems about how the user is going interact with the design. The process of getting there is exactly the same as solving a programming problem.

I think there is a lot of ebb and flow if you don't typecast yourself. As a young kid I was quite interested in the arts. I remember spending a lot of time drawing and honing my visual skills because that's what I enjoyed doing. As I got a little older, I became fascinated by logic problems, remember spending a lot of time learning how to program.

Interestingly, as it relates to this discussion, now that I have grown older still, I actually have become much more interested in business and is one of the reasons why I follow this website. While I've closed a few deals along the way, my business deal abilities definitely lag behind the aforementioned skill sets. That I chalk that up to being much less experienced, not because of any genetic hinderances, however.

It is of my opinion that the biggest limiting factor is time. I was, perhaps, lucky that I started young which afforded me more time to put focus on both design and programming. Whereas for someone else who started programming in college it becomes difficult to fit in time for other interests, such as learning design. I know I spend less time doing business type work than I would otherwise like to because my plate is already full with other jobs. Because of that I miss the opportunity to grow in that area.

If you do project-based work professionally, each project can come with its own set of technologies and related experiences. Combine that with a few personal side using another set of technologies, and the array of technologies you are experienced with can grow pretty rapidly.

As someone who tries to be a master of all, I don't see anything ridiculous about the requirements. If your passion is cars, you're likely to have some knowledge in all of those areas just because you love cars, if for no other reason.

What I found funny, and unfortunately all too true, was the pay offering. They want it all, but are only willing to pay slightly above minimum wage to get it.

Source? From what I can gather, Android barely outsells the iPhone alone. The iPad and the iPod touch sell millions more.

What is interesting is driving force behind so many more developing for Android. What is the cause?

* It is not the profit.

* It is not the user base. Unless your app only appeals to smartphone users, iOS outsells Android by leaps and bounds.

It is, perhaps, an indication that Android is winning in the minds of geeks who go on to write their own software for the platform they use, while the average Joe continues to use iOS and is willing to pay someone else to write the software.

Not key/value, but Mobile CouchBase (CouchDB) supports iOS and apps using it have been approved for the App Store.

An interesting point to note is that Mobile CouchBase is primarily written in Erlang, so porting any existing key/value stores is not dependant on their native language being C or C++.

It seems to me that the real reason is that the attributes one posses to drive them through college are also valuable attributes in business success.

Someone who has no interest in working hard to attain good grades in high school and therefore does not go to college is, generally speaking, someone who has no interest in working hard to get a good job. However, if you took one of those employed college grads and stripped them of their degree, I think we would find their success in business would remain unchanged. It is the person, not the degree, that leads to employment.

Ultimately, we simply do not have enough information to reach any conclusions from the data.