skidooer
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.
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.
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.
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.
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.
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.
Automatic compilation of coffee scripts is nice in development, but not overhead you want to add for production anyway.
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.
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 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?
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.
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.
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.
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?
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?
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.
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.
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.
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.
* 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.
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++.
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.