having used one the new mouse for a little while today, i must say the scroll ball is definitely tactile. I can't tell if its rolling or what, but I can feel it. It also makes some noise too, but I can't get past the tactile sensation. My coworkers can't either.
The regular buttons are also tactile, I can feel it click. This is definitely a really awesome mouse.
To say its a 'step backwards' is really an uninformed position.
I had this problem as well, there is a very strong sense that jython is a unsupported project - more importantly, it has no users. Without an active user and development base with releases at some interval less than 3 years, an open source project can be quite a bit less attractive.
In the end what I wanted to do was write jython in eclipse, compile to.class files and basically implement part of my system in Jython. The Eclipse-Jython mode doesn't really support that so well, so I ended up going with Java 1.5 instead.
Ah yes, we've seen the multicast group table problem. Basically you run into it and your system instantly crashes and suffers huge difficult to recover problems. I wasn't directly involved, but we have put in place migration paths away from tibco. Of course we were doing several things wrong:
- Dont have HUGE subject names - significantly reduces performance I have been told. - dont use multicast for point to point RPC-like services.
Of course its intensely attractive since you can just run a program, not worry about sockets and stuff, and send and receive messages with no problems. But the very same attractiveness has allowed us to build a big pile of crappy middleware ontop of rv. arrrghh!
As for the software "router" daemons (rvrd), we use them to cross over WAN links. This in my experience has been the worst part, especially when you reach low-grade packet loss. What ends up happening is your entire message stream is sent on 1 TCP socket, and it ends up with a max thruput of about 20-30kB/sec so you end up with huge buffering which rvrd ends up unable to recover from. It has made me cry a few times.
I wonder if NYSE uses tibco rendevouz for their message transport "bus". My work uses this software, and our usage of it has stressed it to extremes and you can end up with message storm issues.
FYI this system is a multicast-based publish-subscribe system. The multicast thing tends to be a wash IMHO, especially since many people use it for queues, rather than true 1 to many messaging.
Re:Maintainability of Perl code?
on
Perl Medic
·
· Score: 1
re #2:
IF the only magic I had do deal with was 'open or die' I would be jumping with joy. There is plenty of other magic, for example the whole context changes meaning of operators significantly.
I value consistency in a language... Larry's whole 'postmodern' thing aside.
Re:Using a new language is usually not an option
on
Perl Medic
·
· Score: 1
no.
You can become the saviour. Just for gods sake don't tell anyone you're using lisp, or else you'll never get it done.
The reason why ID is not science is because it does not make falsifiable statements. You can never "prove" any statement to be true, but you can always prove it to be false. Thus a scientific theory has several components: - predictions - falsifiable statements
Now when we talk about ID it provides 'predictions' - ones like "you will see humans", etc. Not really anything amazing. It also does not provide falsifiable statements.
This has nothing to do with 'repeatable' and 'experiments'. ID doesn't even get that far along the scientific track before it gets derailed.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 4, Insightful
"Design by committee" is not a way towards excellence. Excellence often comes in small doses and grows from there.
Let me give you an example from my work. I designed an software monitoring system which read values from our Oracle databases, put the values into RRD files and had a flexible configuration that allowed me to quickly create new sites as copies of other sites. Also I added dependencies and suppression, etc. I designed it to _MY_ specs, what _I_ wanted. But I wrote it in a flexible manner. It's now being used by over 200 people and stands a fair chance at company wide adoption. Not because I asked what people wanted, but because I chose a good solution (not the mythical "best" solution) which worked for me (I had a complex use case fortunately), and made it easily extendable. Now people are feeding data into the system from almost everywhere, and the whole system was rearchitected from a cron job to a continiously running set of daemons. Because of the modular nature of my design it allowed for this redesign easily.
So I think what Apple did rules. They didn't ask requirements from anyone, they had a flash of inspiration, created something awesome that works good for them, and then said 'hey, if you want to use this, go ahead!'
Apple never considered asking other Unices because they wanted something that worked, and also wanted to deliver too.
I completely agree with you! I'd also like to point out there IS a CLI to spotlight. If you read the 200 features page at apple.com you will see the name of the command on the lower right hand side.
One thing I really hate about 'hacker' type is the denigration of all things GUI. The unspoken subtext is "GUIs are inefficient, only lusers use them, they aren't as powerful as CLIs, they are easy to write anyways". Of course good luck using a CLI that does CAD or provide the features of FCP (Final cut pro, video editing s/w).
The final bit of arrogance is the indication that a good GUI is "no big deal". This is so incredibly insulting to those who spent a lifetime engineering superior user interfaces to make human computer interaction less buggy! I for one respect good UI designers, because there sure aren't many of them (goddamn does KDE and GNOME look like butt. While they may have good graphic artists, that is NOT the same as good user interface designers).
The whole hacker superiority is so backwards and is definitely limiting the extent of the computer revolution. At this point in our usage of computers, they are viewed more of a hassle than a benefit, and I don't see many people trying to make that better!
100% Linux based. Including our Oracle systems. There was an article in one of the Oracle trade magazines talking about our switch to Linux as the platform OS for our Oracle systems - replacing HPUX & PaRISC hardware.
Biopolar is very well understood and is one of the depressions which responds very nicely to drugs. Webmd and google are you friends, just check things out.
It sounds its really hard to be in your position - you can see the problems, but since you aren't the Sr Software whatever, its somehow "not your place" to talk about or suggest solutions.
I agree that managers need to be more technically cogent of what they managing - a truely good manager takes the feedback and recognizes their own limitation. I can truly say i'm very lucky and my managers are both ex-techs and are also very dedicate to the concept of _management_ - mentoring and growing people, providing his team with the resources and things we _need_ to perform. It's great.
most of the questions we ask are problem solving questions. and not of the lame-assed variety of "why are manhole covers round". Ultimately I don't care if a candidate knows the details of STL, but if they lack general CS knowledge - which is what we are really looking for - that is a clear sign. Common mistakes that can hurt you: - not asking for clarification on ambiguous questions (they are DELIBERATELY ambiguous to encourage you to ask questions) - Not walking me through the solution. I want to see how you think about things, this isn't multiple answer! - Inability to code - unawareness of fundamental issues, eg: if you're an "expert in C++" then you should be very familiar with stack vs heap based storage. - Unwillingness to solve questions you don't know the answer to. Sometimes I get interviewers who say 'pass' to a question. I guess they think they're on a game show.
The range of poor answers is shocking. We're not talking about "i forgot O notation" or "I can't remember the different ways of accessing map", etc. I really wish we could hire more people, but hiring weak candidates puts an undue burden on the company and is a net loss overall.
It may be hard to see, but I assure you, we are not dinging people on trivial matters. Also all our in-house interviews go through 5 or 6 interviewers and we all independently write up our feedback. If I came across someone who had strong problem solving skills, and only ok knowledge in C++ or Java, I'd pick them in an instant.
The referral system at my work is aggressively chased now, which is great.
As for our recruiters not doing anything... surfing job sites, posting job listings, farming resumes, entering them into our (custom) system, doing initial feasibility (no C++ or Java experience? Not likely to be hired!), doing scheduling - chasing after candidates, etc. These are very time consuming jobs, and I am VERY glad we have people to do them for us.
As for our process - perhaps our process is cutting out the super stars we need, or perhaps they aren't there to find? It's a tough question we ponder all the time - as I said before we're actually trying to _HIRE_ people, not brag to people how smart we are and they aren't. If you think you're qualified, then look for my other post and apply.
Part of a Sr engineer is CREATING the value proposition for refactoring. Management isn't something that just happens to you, it's also something you have to take a part in. You need to manage upwards - yeah it's hard, but if it wasn't hard, would it still be worth doing?
As for subclassing, my coworker says - NO, don't subclass, its the 2nd strongest relationship in C++, the most being friendship.
I have been told that colleges don't really teach OO design - it's just one of those skills you pick up. I think is is very irresponsible of them, and companies shouldn't put up with it.
Look beyond the syntax to the meat of the question. I've seen people use lists when random access was necessary. People would use a list and not know why they were doing so. This is computer _science_ not computer-guess-work.
Most collections support 'getItem( i )' and you can implement it in list, obviously your solution is going to be pretty expensive - O( i ), rather than O( 1 ) of vector. But there are other reasons to pick vector vs list. I find that people just DONT understand the trade offs at all.
The devil is in the details. To say that C++ and Objective C, and Java are the same indicates to me you don't know those very well. Yes they are all 'OO', yes they all support objects and methods, etc, but there are many other details. For example, compare and contrast the method dispatching technology in those languages. Also while you're at it, compare the memory allocation and management techniques. I would be expecting the word 'dynamic binding' in your answers.
The details you denigrate can mean the difference between taking 2 weeks to solve an issue, and taking 1 day to solve the same issue.
We dont have those problems. Resume feasibility is not heavily filtered by the recruiters. Hiring managers review quite a bit of the resumes that come in the door, and ask recruiters to set up phone screens. Our recruiters generally don't give filtering interviews or phone screens. The actual 'yes or no' types of phone screens and decisions are completely left up to the interviewing engineers.
Obviously the weakest point is we have to decide from your resume if you are worth interviewing, but there really isn't much _we_ can do to fix that problem. All I can say is write better resumes!
After reading many resumes and interviewing people, I firmly believe that a solid track record of implementing projects is 100% more important than 'buzzword compliance'. I carry this attitude into all my interviews (ultimately all candidates MUST know Java and/or C++ fairly well, but that is really the maximum of technical requirements that I apply).
While industry may be dumbassed about recruiting, I think our practices are fairly good. Everything can be made better, but I don't think we fall for typical pitfalls.
Want to move to Seattle? I'm in a similar boat as the parent poster... we are located in Seattle (not about to change) and we are 100% willing to relocate new hires. This is _standard_ policy - you don't have to be a 10 star employee to qualify - if you pass interviews and we extend an offer we'll relocate you.
Companies can only get away with this while H1Bs feel threatened with deportation if they speak out against their employers. The solution is to either: - No immigration (not feasable) - Better more permanent immigration
In the second scenario, immigrants would feel more comfortable demanding better pay because their existence in the US is not threatened by 1 boss who wants to reduce salary expenses.
It's not 30 minutes, its a in depth 60 minute screen. Our requirements are not very strenuous for someone who would call themselves 'experienced'. What I tend to find is people don't know basic things such as when to choose between using a tree and a hash, the complexity of operator[] in a list vs a vector (to use STL language), OO definition (what is polymorphism again?), OO design (A Card derives from a Deck of cards... what!?), basic tool knowledge (lets spend 2 weeks writing a C program that does what a 1 line regexp in grep does).
These are _NOT_ complex things. I think of myself as VERY generous in phone screens - I recognize nervousness, being slow in remembering things, but what I find is a total lack of knowledge in some key areas. I wouldn't want a developer who doesn't know what kind of basic data structures to choose (we've seen people choose maps instead of lists in some situations).
I take my phone screen duties VERY seriously... I'm not trying to be a show off - I just want competent co-workers! I want them, and I want them NOW.
In the end we are not trying to decide if we want to hire someone on the phone, we are trying to assess their technical abilities to see if they would do well in an in person interview.
In a technical field it is very easy to reject candidates in a phone screen interval - total lack of knowledge, unwillingness to solve problems, lack of interest in the job, all these things can kill you within 45-60 minutes.
Slashdot Mirror
having used one the new mouse for a little while today, i must say the scroll ball is definitely tactile. I can't tell if its rolling or what, but I can feel it. It also makes some noise too, but I can't get past the tactile sensation. My coworkers can't either.
The regular buttons are also tactile, I can feel it click. This is definitely a really awesome mouse.
To say its a 'step backwards' is really an uninformed position.
I had this problem as well, there is a very strong sense that jython is a unsupported project - more importantly, it has no users. Without an active user and development base with releases at some interval less than 3 years, an open source project can be quite a bit less attractive.
.class files and basically implement part of my system in Jython. The Eclipse-Jython mode doesn't really support that so well, so I ended up going with Java 1.5 instead.
In the end what I wanted to do was write jython in eclipse, compile to
Ah yes, we've seen the multicast group table problem. Basically you run into it and your system instantly crashes and suffers huge difficult to recover problems. I wasn't directly involved, but we have put in place migration paths away from tibco. Of course we were doing several things wrong:
- Dont have HUGE subject names - significantly reduces performance I have been told.
- dont use multicast for point to point RPC-like services.
Of course its intensely attractive since you can just run a program, not worry about sockets and stuff, and send and receive messages with no problems. But the very same attractiveness has allowed us to build a big pile of crappy middleware ontop of rv. arrrghh!
As for the software "router" daemons (rvrd), we use them to cross over WAN links. This in my experience has been the worst part, especially when you reach low-grade packet loss. What ends up happening is your entire message stream is sent on 1 TCP socket, and it ends up with a max thruput of about 20-30kB/sec so you end up with huge buffering which rvrd ends up unable to recover from. It has made me cry a few times.
I wonder if NYSE uses tibco rendevouz for their message transport "bus". My work uses this software, and our usage of it has stressed it to extremes and you can end up with message storm issues.
FYI this system is a multicast-based publish-subscribe system. The multicast thing tends to be a wash IMHO, especially since many people use it for queues, rather than true 1 to many messaging.
re #2:
IF the only magic I had do deal with was 'open or die' I would be jumping with joy. There is plenty of other magic, for example the whole context changes meaning of operators significantly.
I value consistency in a language... Larry's whole 'postmodern' thing aside.
no.
You can become the saviour. Just for gods sake don't tell anyone you're using lisp, or else you'll never get it done.
The reason why ID is not science is because it does not make falsifiable statements. You can never "prove" any statement to be true, but you can always prove it to be false. Thus a scientific theory has several components:
- predictions
- falsifiable statements
Now when we talk about ID it provides 'predictions' - ones like "you will see humans", etc. Not really anything amazing. It also does not provide falsifiable statements.
This has nothing to do with 'repeatable' and 'experiments'. ID doesn't even get that far along the scientific track before it gets derailed.
"Design by committee" is not a way towards excellence. Excellence often comes in small doses and grows from there.
Let me give you an example from my work. I designed an software monitoring system which read values from our Oracle databases, put the values into RRD files and had a flexible configuration that allowed me to quickly create new sites as copies of other sites. Also I added dependencies and suppression, etc. I designed it to _MY_ specs, what _I_ wanted. But I wrote it in a flexible manner. It's now being used by over 200 people and stands a fair chance at company wide adoption. Not because I asked what people wanted, but because I chose a good solution (not the mythical "best" solution) which worked for me (I had a complex use case fortunately), and made it easily extendable. Now people are feeding data into the system from almost everywhere, and the whole system was rearchitected from a cron job to a continiously running set of daemons. Because of the modular nature of my design it allowed for this redesign easily.
So I think what Apple did rules. They didn't ask requirements from anyone, they had a flash of inspiration, created something awesome that works good for them, and then said 'hey, if you want to use this, go ahead!'
Apple never considered asking other Unices because they wanted something that worked, and also wanted to deliver too.
I completely agree with you! I'd also like to point out there IS a CLI to spotlight. If you read the 200 features page at apple.com you will see the name of the command on the lower right hand side.
One thing I really hate about 'hacker' type is the denigration of all things GUI. The unspoken subtext is "GUIs are inefficient, only lusers use them, they aren't as powerful as CLIs, they are easy to write anyways". Of course good luck using a CLI that does CAD or provide the features of FCP (Final cut pro, video editing s/w).
The final bit of arrogance is the indication that a good GUI is "no big deal". This is so incredibly insulting to those who spent a lifetime engineering superior user interfaces to make human computer interaction less buggy! I for one respect good UI designers, because there sure aren't many of them (goddamn does KDE and GNOME look like butt. While they may have good graphic artists, that is NOT the same as good user interface designers).
The whole hacker superiority is so backwards and is definitely limiting the extent of the computer revolution. At this point in our usage of computers, they are viewed more of a hassle than a benefit, and I don't see many people trying to make that better!
Ok, enough!
100% Linux based. Including our Oracle systems. There was an article in one of the Oracle trade magazines talking about our switch to Linux as the platform OS for our Oracle systems - replacing HPUX & PaRISC hardware.
It's all good baby!
Biopolar is very well understood and is one of the depressions which responds very nicely to drugs. Webmd and google are you friends, just check things out.
Sure, if you have good fundamentals and good problem solving skills, you'll pick up C++ fairly easily.
If you have the experience of working on big projects, getting things done and so forth - please apply. Just look at my other posts for how to do so.
DUDE! Are we on the same team? Ryan in COFS here... and you?
Sounds like a few teams and people I know.
I completely 100% agree with your prior posting... we have the same experience with hiring people.
It sounds its really hard to be in your position - you can see the problems, but since you aren't the Sr Software whatever, its somehow "not your place" to talk about or suggest solutions.
I agree that managers need to be more technically cogent of what they managing - a truely good manager takes the feedback and recognizes their own limitation. I can truly say i'm very lucky and my managers are both ex-techs and are also very dedicate to the concept of _management_ - mentoring and growing people, providing his team with the resources and things we _need_ to perform. It's great.
The problematic people we have can't even make the statement you made and back it up.
I'll say it again, we're talking major lack of skills. It really drives me nuts.
most of the questions we ask are problem solving questions. and not of the lame-assed variety of "why are manhole covers round". Ultimately I don't care if a candidate knows the details of STL, but if they lack general CS knowledge - which is what we are really looking for - that is a clear sign. Common mistakes that can hurt you:
- not asking for clarification on ambiguous questions (they are DELIBERATELY ambiguous to encourage you to ask questions)
- Not walking me through the solution. I want to see how you think about things, this isn't multiple answer!
- Inability to code - unawareness of fundamental issues, eg: if you're an "expert in C++" then you should be very familiar with stack vs heap based storage.
- Unwillingness to solve questions you don't know the answer to. Sometimes I get interviewers who say 'pass' to a question. I guess they think they're on a game show.
The range of poor answers is shocking. We're not talking about "i forgot O notation" or "I can't remember the different ways of accessing map", etc. I really wish we could hire more people, but hiring weak candidates puts an undue burden on the company and is a net loss overall.
It may be hard to see, but I assure you, we are not dinging people on trivial matters. Also all our in-house interviews go through 5 or 6 interviewers and we all independently write up our feedback. If I came across someone who had strong problem solving skills, and only ok knowledge in C++ or Java, I'd pick them in an instant.
The referral system at my work is aggressively chased now, which is great.
As for our recruiters not doing anything... surfing job sites, posting job listings, farming resumes, entering them into our (custom) system, doing initial feasibility (no C++ or Java experience? Not likely to be hired!), doing scheduling - chasing after candidates, etc. These are very time consuming jobs, and I am VERY glad we have people to do them for us.
As for our process - perhaps our process is cutting out the super stars we need, or perhaps they aren't there to find? It's a tough question we ponder all the time - as I said before we're actually trying to _HIRE_ people, not brag to people how smart we are and they aren't. If you think you're qualified, then look for my other post and apply.
Part of a Sr engineer is CREATING the value proposition for refactoring. Management isn't something that just happens to you, it's also something you have to take a part in. You need to manage upwards - yeah it's hard, but if it wasn't hard, would it still be worth doing?
As for subclassing, my coworker says - NO, don't subclass, its the 2nd strongest relationship in C++, the most being friendship.
I have been told that colleges don't really teach OO design - it's just one of those skills you pick up. I think is is very irresponsible of them, and companies shouldn't put up with it.
Look beyond the syntax to the meat of the question. I've seen people use lists when random access was necessary. People would use a list and not know why they were doing so. This is computer _science_ not computer-guess-work.
Most collections support 'getItem( i )' and you can implement it in list, obviously your solution is going to be pretty expensive - O( i ), rather than O( 1 ) of vector. But there are other reasons to pick vector vs list. I find that people just DONT understand the trade offs at all.
Don't be a jerk.
The devil is in the details. To say that C++ and Objective C, and Java are the same indicates to me you don't know those very well. Yes they are all 'OO', yes they all support objects and methods, etc, but there are many other details. For example, compare and contrast the method dispatching technology in those languages. Also while you're at it, compare the memory allocation and management techniques. I would be expecting the word 'dynamic binding' in your answers.
The details you denigrate can mean the difference between taking 2 weeks to solve an issue, and taking 1 day to solve the same issue.
It's not called silicon forest for nothing... there are other companies located here!
Having said that, you should visit http://www.amazon.com/jobs/
We dont have those problems. Resume feasibility is not heavily filtered by the recruiters. Hiring managers review quite a bit of the resumes that come in the door, and ask recruiters to set up phone screens. Our recruiters generally don't give filtering interviews or phone screens. The actual 'yes or no' types of phone screens and decisions are completely left up to the interviewing engineers.
Obviously the weakest point is we have to decide from your resume if you are worth interviewing, but there really isn't much _we_ can do to fix that problem. All I can say is write better resumes!
After reading many resumes and interviewing people, I firmly believe that a solid track record of implementing projects is 100% more important than 'buzzword compliance'. I carry this attitude into all my interviews (ultimately all candidates MUST know Java and/or C++ fairly well, but that is really the maximum of technical requirements that I apply).
While industry may be dumbassed about recruiting, I think our practices are fairly good. Everything can be made better, but I don't think we fall for typical pitfalls.
Want to move to Seattle? I'm in a similar boat as the parent poster... we are located in Seattle (not about to change) and we are 100% willing to relocate new hires. This is _standard_ policy - you don't have to be a 10 star employee to qualify - if you pass interviews and we extend an offer we'll relocate you.
Companies can only get away with this while H1Bs feel threatened with deportation if they speak out against their employers. The solution is to either:
- No immigration (not feasable)
- Better more permanent immigration
In the second scenario, immigrants would feel more comfortable demanding better pay because their existence in the US is not threatened by 1 boss who wants to reduce salary expenses.
It's not 30 minutes, its a in depth 60 minute screen. Our requirements are not very strenuous for someone who would call themselves 'experienced'. What I tend to find is people don't know basic things such as when to choose between using a tree and a hash, the complexity of operator[] in a list vs a vector (to use STL language), OO definition (what is polymorphism again?), OO design (A Card derives from a Deck of cards... what!?), basic tool knowledge (lets spend 2 weeks writing a C program that does what a 1 line regexp in grep does).
These are _NOT_ complex things. I think of myself as VERY generous in phone screens - I recognize nervousness, being slow in remembering things, but what I find is a total lack of knowledge in some key areas. I wouldn't want a developer who doesn't know what kind of basic data structures to choose (we've seen people choose maps instead of lists in some situations).
I take my phone screen duties VERY seriously... I'm not trying to be a show off - I just want competent co-workers! I want them, and I want them NOW.
In the end we are not trying to decide if we want to hire someone on the phone, we are trying to assess their technical abilities to see if they would do well in an in person interview.
In a technical field it is very easy to reject candidates in a phone screen interval - total lack of knowledge, unwillingness to solve problems, lack of interest in the job, all these things can kill you within 45-60 minutes.