Furthermore, PS isn't a low-level printer file. It is a page description language, and a very powerful one at that. It was the language used to implement GUIs for NeXT's NeWS, and its offshoot PDF is used on the Aqua GUI.
I worked for a dot-com that built an application to do just this. Our focus was on product management, to automatically classify incoming email about products to specific categories in a hierarchy. The classification part was very general and could have been used for just this purpose.
I say could have because it got sucked down the drain in late 2000 with all of the companies that didn't have a damn thing to offer. Lesson #1: make sure your CEO gets along with your venture partner.
Agreed. Well-written code should be readable, and design by contract is an effective way to improve the self-documentation of source code.
As far as hiring people, I've hired plenty and ran across few that interviewed well, but turned out to be a disaster.
Oh, yeah. Been there, done that. Every time I flip the bozo bit on somebody I mentally review their interview and what should have tipped me off. Thanks for the link.
Hey, don't knock the guys with shitty grades. I was too busy with personal coding projects to do things like "homework" and "attend class". Yeah, I had a hell of a time landing my first job but once I did, I blew the doors off of the coders that sported 4.0's and no initiative.
(GPA > 3.5) != wizBangDeveloper
In fact, most of the coders that I know who had excellent grades had a lot of trouble translating collegiate success to their careers. It's a very different game.
As far as looking for strong OO principles, I usually go through an exercise that demonstrates the candidate's knowledge of inheritance, encapsulation, polymorphism and late binding. Generally, I'll have the candidate design a small (~6 class) hierarchy to solve a textbook problem, then exercise the design via a set of use cases that further explore his understanding.
As we work in Java, I also throw in a few trivia questions that are relevant to the design. I'm not a big fan of language trivia, but these questions do tend to weed out the newbies.
"Rigorous design" is harder. As part of our methodology, the architects (myself included) produce a conceptual UML design that satsifies all identified use cases for the project at hand. "Rigorous" is a bit of an overstatement here. We follow the thinking that discoveries made during the development process will greatly influence the end design, so I don't like to tie engineers' hands with a micro-managing digram. As far as candidates are concerned, I look for genuine quality in the design produced during the above exercise, and also look for evidence of a commitment to upfront design when verbally reviewing prior works. The "rigorous design" statement was really more a shot at the OSS projects that forgoe any design.
Lastly, source code is not documentation. You might describe it as the ultimate functional spec, but documentation it is not. Documentation is intended to provide a high-level overview of the class/package/application/system to a person not familiar with it. Not only does it ease the learning curve for new developers, it will be required if your project is ever adopted by a third party organization (e.g. your employer strikes up a horizontal partnership deal). When people like Bertram Meyer espouse the need for documentation integrated with the source code, it's not because they can't understand the code. It is because proper documentation is key to creating a maintainable, reusable system. Also, when the documentation is integrated with the source there is much more of a motivation to keep it in date. Monolithic UML diagrams are a whole 'nother story, and that's why I don't do them.
Yes, cowboys abound in every development environment. My point is that the predominant OSS culture encourages a style of development that damns all the consequences and forges full speed ahead. Yes, this exists in commercial development(I have witnessed it first hand). I was trying to explain that a fresh-out developer needs to be wary of this behavior, as it will lead to a jungle of pitfalls.
I haven't spent enough time tooling around in Apache or Linux source to comment on the code. I just build and install these things. I will say that they seem to have acquired an astonishing amount of bureaucracy. Perhaps it is a natural evolution of all software that greatly exceeds the designers' original goal. A foolproof recipe for software bloat is one part niche success and two parts grass-roots (or any) marketing. Put both in a blender at hit "frappe".
First, let me qualify my post: * I regularly evaluate candidates for employment in a disciplined software development environment. * I fully support Open Source Software.
That being said, the open source code that I have reviewed has been of low quality in the areas that I look for in evaluating candidates, including: * strong OO principles * rigorous design * excellent documentation
The few open source projects that I have tried to contribute to (freenet being one) actually scoffed at these points, claiming them to be the stuff of over-educated highbrows, stuffed-shirt engineer etc.
If that is the culture of open source software, then so be it. However, in the world of commercial software development, these are very real, very important requirements. The best hacker is useless if he creates an unmaintainable system.
The point is that, from my experience, OSS projects and commercial development are two very different environments (granted, many commercially-developed codebases are poorly engineered, hackfully constructed and are devoid of documentation). OSS projects will get you acclimated to integrated your work with that of other developers', but may also indoctrinate you in an unrealistic development environment.
In other words, it produces a lot of cowboys. Don't expect your bazaar approach to be successful in the cathedral.
I have been successfully and happily using Linux with Ximian as by desktop for about six months. Next week I am going to have to start using Windoze again unless somebody can recommend a way to view Quicktime 5 w/ Sorenson on Linux, both standalone and embedded within a webpage. I also need SMIL support.
I've tried vmware, its Quicktime performance is pathetic (I have an 800Mhz machine w/ 256 MB RAM). I've also tried the Crossover plugin with little to no success.
Why the heck doesn't apple release a Quicktime for Linux?
DOC++ looks useful, too. I spent 7 years coding C/C++, and moved into the Java world 3 years ago. One of the greatest assets to the Java platform is the self-documentation supported by JavaDoc (that is, comments in the code are used to compile the API reference manual). Granted, your project doesn't conform to the DOC++ commenting syntax, but it should be useful for viewing the class hierarchy and browsing the API.
Together from TogetherSoft is an excellent reverse-engineering package for C++ and Java. There is a free eval that does most everything, but will not print or export diagrams. The full-version license is pretty pricy (around $3k) from what I hear, the website doesn't list a price.
Also, to find references to particular methods and subroutines, LXR is very useful. LXR is designed for use with the Linux codebase, but it is generic enough to be used with any C/C++ project. It takes a couple of hours to get running, but it is free and very cool. I just wish it would support Java.
Real world programming experience doesn't translate very well into academic computer science. I started programming when I was 12, and had learned a few languages and writtem some simple games when I enrolled at UT Austin. I thought it was going to be a total breeze. I was totally wrong. Academic CS at a top institution is very much into theory, proving concepts, and understanding the "science" part of computer science. To be blunt, you won't spend a whole lot of time coding. You _will_ spend a lot of time doing three-page predicate calculus problems, proofs of theorems, analysis of protocols, thought exercises on patterns of execution, etc. etc. etc. I'd estimate that the amount of time I spent actually coding in UT's CS program was about 10% vs the reading and paperwork. Plus, any accredited University won't let you skate by on CS credits alone. You'll need the regimen of liberal arts, math, philosophy, government, writing and natural sciences to complete your degree.
Plan on spending at least three years. Of course, you could try enjoying your stay and take a whole 4, 5, or 6 years.:) Despite what/. might make you believe, college can be pretty damn fun and sometimes even rewarding.
On the other hand, some of the best coders I have worked with had no degree, or had a degree in something like English or math. Just avoid EE at all costs, if you want to be a decent developer.
What nobody is talking about, at least directly, is that these hijackers used items that are allowed through the security at airports. A 4-inch knife is allowed through security. I don't know, but my Stanley cardboard-cutter measures up at about 3/4". I haven't heard measurements of the other knives wielded by the hijackers, but 4-inches is pretty intimidating. Everybody is screaming for more security at airports and on airplanes, which is most certainly needed. However, removing our basic civil liberties is not. Especially when you consider the evidence that the hijackers boarded with weapons that were probably discovered and allowed by the current regulations!
Arm the flight crew. Put a flight marshall on board (all flights!). Don't allow obvious weapons in passengers' immediate possession or carry-ons. Train the American public in how to endure and/or subvert a terrorist attack. These are all simple solutions to last week's tragedy that would have prevented it without posing major challenges to the basic rights guaranteed to Americans by our Constitution.
An instrument of evolution in the birthplace of M$ and grunge music. We're doomed.
entry may be the same, advancement differs
on
CS vs CIS
·
· Score: 1
I have a CS degree and about 7 years of experience working with developers with CS, EE, Math, English, MIS, and CIS backgrounds. Yes, you can get a job in development with any of these degrees, and entry-level usually pays the same in a given organization, regardless of degree. However, CS, Math and English majors typically make "better" programmers. My guess is that these backgrounds foster problem-solving skills at the abstract level and an appreciation for the finer points of the discipline. I have worked with a few EE developers that were very good, but people with this background usually sacrifice code quality for "getting the job done", and make poor designers. I have a suspicion that this is due to a lack of respect for software engineering, but haven't confirmed this. CIS and MIS majors usually just don't "get it". They can do the day- to-day duties of rote programming, but fail to make defensible choices in designs and algorithms. MIS/CIS people often implement such atrocities as N-cubed complexity algorithms and cut-and-paste coding. The point of this is that your advancement in the field will be governed by your performance. If you want to quickly move up the ranks from junior developer to senior engineer to technical lead or even architect, you'll probably want the training that a CS degree offers. Granted that a degree is no guarantee of future success--you have to do your part of keeping your skills current and learning from the senior people in your organization--but it is a good place to start. My advice to anyone that wants to succeed in software engineering: if you are looking for the easiest way in, look for another career.
Slashdot Mirror
Furthermore, PS isn't a low-level printer file. It is a page description language, and a very powerful one at that. It was the language used to implement GUIs for NeXT's NeWS, and its offshoot PDF is used on the Aqua GUI.
Most academic publications are delivered in either Postscript or TeX, it's not unusual.
Sheesh, this guy needs a job.
http://monorails.org/tMspages/Niles.html
I say could have because it got sucked down the drain in late 2000 with all of the companies that didn't have a damn thing to offer. Lesson #1: make sure your CEO gets along with your venture partner.
No, I'm not bitter. Much.
Agreed. Well-written code should be readable, and design by contract is an effective way to improve the self-documentation of source code.
As far as hiring people, I've hired plenty and ran across few that interviewed well, but turned out to be a disaster.
Oh, yeah. Been there, done that. Every time I flip the bozo bit on somebody I mentally review their interview and what should have tipped me off.
Thanks for the link.
Hey, don't knock the guys with shitty grades. I was too busy with personal coding projects to do things like "homework" and "attend class". Yeah, I had a hell of a time landing my first job but once I did, I blew the doors off of the coders that sported 4.0's and no initiative.
(GPA > 3.5) != wizBangDeveloper
In fact, most of the coders that I know who had excellent grades had a lot of trouble translating collegiate success to their careers. It's a very different game.
As far as looking for strong OO principles, I usually go through an exercise that demonstrates the candidate's knowledge of inheritance, encapsulation, polymorphism and late binding. Generally, I'll have the candidate design a small (~6 class) hierarchy to solve a textbook problem, then exercise the design via a set of use cases that further explore his understanding.
As we work in Java, I also throw in a few trivia questions that are relevant to the design. I'm not a big fan of language trivia, but these questions do tend to weed out the newbies.
"Rigorous design" is harder. As part of our methodology, the architects (myself included) produce a conceptual UML design that satsifies all identified use cases for the project at hand. "Rigorous" is a bit of an overstatement here. We follow the thinking that discoveries made during the development process will greatly influence the end design, so I don't like to tie engineers' hands with a micro-managing digram. As far as candidates are concerned, I look for genuine quality in the design produced during the above exercise, and also look for evidence of a commitment to upfront design when verbally reviewing prior works. The "rigorous design" statement was really more a shot at the OSS projects that forgoe any design.
Lastly, source code is not documentation. You might describe it as the ultimate functional spec, but documentation it is not. Documentation is intended to provide a high-level overview of the class/package/application/system to a person not familiar with it. Not only does it ease the learning curve for new developers, it will be required if your project is ever adopted by a third party organization (e.g. your employer strikes up a horizontal partnership deal). When people like Bertram Meyer espouse the need for documentation integrated with the source code, it's not because they can't understand the code. It is because proper documentation is key to creating a maintainable, reusable system. Also, when the documentation is integrated with the source there is much more of a motivation to keep it in date. Monolithic UML diagrams are a whole 'nother story, and that's why I don't do them.
Yes, cowboys abound in every development environment. My point is that the predominant OSS culture encourages a style of development that damns all the consequences and forges full speed ahead. Yes, this exists in commercial development(I have witnessed it first hand). I was trying to explain that a fresh-out developer needs to be wary of this behavior, as it will lead to a jungle of pitfalls.
I haven't spent enough time tooling around in Apache or Linux source to comment on the code. I just build and install these things. I will say that they seem to have acquired an astonishing amount of bureaucracy. Perhaps it is a natural evolution of all software that greatly exceeds the designers' original goal. A foolproof recipe for software bloat is one part niche success and two parts grass-roots (or any) marketing. Put both in a blender at hit "frappe".
First, let me qualify my post:
* I regularly evaluate candidates for employment in a disciplined software development environment.
* I fully support Open Source Software.
That being said, the open source code that I have reviewed has been of low quality in the areas that I look for in evaluating candidates, including:
* strong OO principles
* rigorous design
* excellent documentation
The few open source projects that I have tried to contribute to (freenet being one) actually scoffed at these points, claiming them to be the stuff of over-educated highbrows, stuffed-shirt engineer etc.
If that is the culture of open source software, then so be it. However, in the world of commercial software development, these are very real, very important requirements. The best hacker is useless if he creates an unmaintainable system.
The point is that, from my experience, OSS projects and commercial development are two very different environments (granted, many commercially-developed codebases are poorly engineered, hackfully constructed and are devoid of documentation). OSS projects will get you acclimated to integrated your work with that of other developers', but may also indoctrinate you in an unrealistic development environment.
In other words, it produces a lot of cowboys. Don't expect your bazaar approach to be successful in the cathedral.
They must have fixed it, because Crossover worked immediately. Thanks for helping me fend off the beast (for now).
I have been successfully and happily using Linux with Ximian as by desktop for about six months. Next week I am going to have to start using Windoze again unless somebody can recommend a way to view Quicktime 5 w/ Sorenson on Linux, both standalone and embedded within a webpage. I also need SMIL support.
I've tried vmware, its Quicktime performance is pathetic (I have an 800Mhz machine w/ 256 MB RAM). I've also tried the Crossover plugin with little to no success.
Why the heck doesn't apple release a Quicktime for Linux?
DOC++ looks useful, too. I spent 7 years coding C/C++, and moved into the Java world 3 years ago. One of the greatest assets to the Java platform is the self-documentation supported by JavaDoc (that is, comments in the code are used to compile the API reference manual). Granted, your project doesn't conform to the DOC++ commenting syntax, but it should be useful for viewing the class hierarchy and browsing the API.
Together from TogetherSoft is an excellent reverse-engineering package for C++ and Java. There is a free eval that does most everything, but will not print or export diagrams. The full-version license is pretty pricy (around $3k) from what I hear, the website doesn't list a price.
Also, to find references to particular methods and subroutines, LXR is very useful. LXR is designed for use with the Linux codebase, but it is generic enough to be used with any C/C++ project. It takes a couple of hours to get running, but it is free and very cool. I just wish it would support Java.
Real world programming experience doesn't translate very well into academic computer science. I started programming when I was 12, and had learned a few languages and writtem some simple games when I enrolled at UT Austin. I thought it was going to be a total breeze. I was totally wrong. Academic CS at a top institution is very much into theory, proving concepts, and understanding the "science" part of computer science. To be blunt, you won't spend a whole lot of time coding. You _will_ spend a lot of time doing three-page predicate calculus problems, proofs of theorems, analysis of protocols, thought exercises on patterns of execution, etc. etc. etc. I'd estimate that the amount of time I spent actually coding in UT's CS program was about 10% vs the reading and paperwork. Plus, any accredited University won't let you skate by on CS credits alone. You'll need the regimen of liberal arts, math, philosophy, government, writing and natural sciences to complete your degree.
:) Despite what /. might make you believe, college can be pretty damn fun and sometimes even rewarding.
Plan on spending at least three years. Of course, you could try enjoying your stay and take a whole 4, 5, or 6 years.
On the other hand, some of the best coders I have worked with had no degree, or had a degree in something like English or math. Just avoid EE at all costs, if you want to be a decent developer.
Free as in beer
Free as in software
Free as in worm author
What nobody is talking about, at least directly, is that these hijackers used items that are allowed through the security at airports. A 4-inch knife is allowed through security. I don't know, but my Stanley cardboard-cutter measures up at about 3/4". I haven't heard measurements of the other knives wielded by the hijackers, but 4-inches is pretty intimidating. Everybody is screaming for more security at airports and on airplanes, which is most certainly needed. However, removing our basic civil liberties is not. Especially when you consider the evidence that the hijackers boarded with weapons that were probably discovered and allowed by the current regulations!
Arm the flight crew. Put a flight marshall on board (all flights!). Don't allow obvious weapons in passengers' immediate possession or carry-ons. Train the American public in how to endure and/or subvert a terrorist attack. These are all simple solutions to last week's tragedy that would have prevented it without posing major challenges to the basic rights guaranteed to Americans by our Constitution.
Yeah, that was where the first office was, but I think you could argue that M$ was born at Lakeside.
An instrument of evolution in the birthplace of M$ and grunge music. We're doomed.
I have a CS degree and about 7 years of experience working with developers with CS, EE, Math, English, MIS, and CIS backgrounds. Yes, you can get a job in development with any of these degrees, and entry-level usually pays the same in a given organization, regardless of degree. However, CS, Math and English majors typically make "better" programmers. My guess is that these backgrounds foster problem-solving skills at the abstract level and an appreciation for the finer points of the discipline. I have worked with a few EE developers that were very good, but people with this background usually sacrifice code quality for "getting the job done", and make poor designers. I have a suspicion that this is due to a lack of respect for software engineering, but haven't confirmed this. CIS and MIS majors usually just don't "get it". They can do the day- to-day duties of rote programming, but fail to make defensible choices in designs and algorithms. MIS/CIS people often implement such atrocities as N-cubed complexity algorithms and cut-and-paste coding. The point of this is that your advancement in the field will be governed by your performance. If you want to quickly move up the ranks from junior developer to senior engineer to technical lead or even architect, you'll probably want the training that a CS degree offers. Granted that a degree is no guarantee of future success--you have to do your part of keeping your skills current and learning from the senior people in your organization--but it is a good place to start. My advice to anyone that wants to succeed in software engineering: if you are looking for the easiest way in, look for another career.