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.
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.
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.
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.
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.