My geek thread
#302
purity of essence
Join Date: Feb 2006
Location: NH
Posts: 2,260
Bikes: 2018 Giant Trance 2, 2019 Trek Farley 7, 2017 Jamis Renegade Exploit
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 37 Post(s)
Likes: 0
Liked 26 Times
in
11 Posts
Until today, I'd forgotten what a kick-ass book Unix Power Tools is.
#303
Senior Member
Join Date: Sep 2008
Location: Murrieta, CA
Posts: 1,035
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
Probably although the logical operators were never a big issue for me for the work I was doing. I must be getting old because sometimes I miss the simplicity of it all.
#304
Banned
Join Date: Sep 2005
Location: Santa Barbara, CA
Posts: 28,387
Bikes: Specialized Tarmac SL2, Specialized Tarmac SL, Giant TCR Composite, Specialized StumpJumper Expert HT
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 2 Times
in
2 Posts
Well when AND/OR/NOT don't do what you expect because they are bitwise instead of logical, it causes problems. Especially if you are calling things in other languages that don't have the same definition of the meaning of TRUE.
#305
Making a kilometer blurry
I used to work at the gun club on step 49. My first job, and I was 14. Mostly loaded trap and skeet. Put two on the arm, throw three against the wall. There were about 12" of busted clay pigeons in the floor of the trap houses. Really sucked when they pulled while you were loading.
#306
slow up hills
Join Date: Mar 2006
Location: Seattle, WA
Posts: 4,931
Bikes: Giant TCR, Redline CX, Ritchey Breakaway, Spec S-works epic
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
#307
My idea of fun
Join Date: Jun 2006
Location: Gainesville, FL
Posts: 9,920
Bikes: '06 Litespeed Tuscany, '02 Kona Lavadome, '07 Giant TCR Advanced, '07 Karate Monkey
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 41 Post(s)
Liked 59 Times
in
36 Posts
Funny language story. I was reviewing someone's code a few weeks ago, in VB6. VB still supports a bunch of the old anachronistic BASIC language features, like line numbers.
I noticed an arbitrary "4:" on one of the lines and I asked him why it was there.
He replied, "I don't know, but it doesn't seem to hurt anything".
I literally facepalmed.
I noticed an arbitrary "4:" on one of the lines and I asked him why it was there.
He replied, "I don't know, but it doesn't seem to hurt anything".
I literally facepalmed.
#308
Senior Member
I never saw that before. Step 38 threw me off for a bit. Heh.
#309
Senior Member
Join Date: Jul 2006
Location: Chester County, PA
Posts: 2,365
Bikes: 2010 Trek Madone 5.5 CAAD9
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 1 Time
in
1 Post
Yup, he said all the BF use is costing his company a lot of $$$ No and trust me no one wants to work there.
He and I would be the only ones with access to look at the report. And I don't care what anyone there does as long as they don't f up their computers and make me have to go onsite.
The guy running the show is a total dictator, control freak and genuine a-hole.
The guy running the show is a total dictator, control freak and genuine a-hole.
#310
Senior Member
My brother is a high end programmer. I asked him about the 2-3 other high end guys at my old job (he is still there). He said that all programmers think their code is better than another "equal" programmer's code.
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
There's also the whole thing with bugs. "It's not a bug, it's a feature."
There was one guy that would razz everyone else on their bugs. When he had a bug he'd quickly add a feature so he could re-release the package with a feature update rather than a bug fix. I forget the way the package naming stuff worked but it was like version.feature.something.bug. So 1.1.2.0 meant 1st version, 1st feature, 2nd something, and no bugs. The one guy would carefully re-release his stuff so the last digit was always zero.
Question is how perfect should you make it. If you make it absolutely bug free it could take too much time (inefficient). If you release things too quickly it'll be buggy (inefficient).
My bro said there were one or two programmers (apparently well known to him but total strangers the other way) who wrote basically bug-free stuff efficiently. He'd talk about them with a lot of respect, kind of like bike racers saying, "Yeah, Voigt is pretty tough".
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
There's also the whole thing with bugs. "It's not a bug, it's a feature."
There was one guy that would razz everyone else on their bugs. When he had a bug he'd quickly add a feature so he could re-release the package with a feature update rather than a bug fix. I forget the way the package naming stuff worked but it was like version.feature.something.bug. So 1.1.2.0 meant 1st version, 1st feature, 2nd something, and no bugs. The one guy would carefully re-release his stuff so the last digit was always zero.
Question is how perfect should you make it. If you make it absolutely bug free it could take too much time (inefficient). If you release things too quickly it'll be buggy (inefficient).
My bro said there were one or two programmers (apparently well known to him but total strangers the other way) who wrote basically bug-free stuff efficiently. He'd talk about them with a lot of respect, kind of like bike racers saying, "Yeah, Voigt is pretty tough".
#311
Senior Member
Join Date: Mar 2010
Location: Northeast Ohio
Posts: 3,215
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
Saw this today. Figure it fits in here:
" Theory is when you know something but it does not work. Practical is when something works, but you don't know why. Engineering combines both. Nothing works and you don't know why."
" Theory is when you know something but it does not work. Practical is when something works, but you don't know why. Engineering combines both. Nothing works and you don't know why."
#313
Boom.
Join Date: May 2010
Location: Pittsburgh -> Cleveland -> San Francisco
Posts: 2,523
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
So for you java experts.
How tough is it to transfer working java code to android? My final project for my programming class has me making a simulation GPS that runs on my computer. It has a standard gui with a couple of radio buttons. The code reads off a .txt file in order to get the coordinates to simulate the GPS.
Would I be able to transfer this code directly on to the android platform?
How tough is it to transfer working java code to android? My final project for my programming class has me making a simulation GPS that runs on my computer. It has a standard gui with a couple of radio buttons. The code reads off a .txt file in order to get the coordinates to simulate the GPS.
Would I be able to transfer this code directly on to the android platform?
#314
Senior Member
Join Date: Aug 2009
Location: Seattle
Posts: 970
Bikes: Giant Defy 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
So for you java experts.
How tough is it to transfer working java code to android? My final project for my programming class has me making a simulation GPS that runs on my computer. It has a standard gui with a couple of radio buttons. The code reads off a .txt file in order to get the coordinates to simulate the GPS.
Would I be able to transfer this code directly on to the android platform?
How tough is it to transfer working java code to android? My final project for my programming class has me making a simulation GPS that runs on my computer. It has a standard gui with a couple of radio buttons. The code reads off a .txt file in order to get the coordinates to simulate the GPS.
Would I be able to transfer this code directly on to the android platform?
#315
Boom.
Join Date: May 2010
Location: Pittsburgh -> Cleveland -> San Francisco
Posts: 2,523
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
But then again, it took me 3 days to figure out the run time error I was getting was being caused by me declaring my main method as private.
#316
Senior Member
Join Date: Aug 2009
Location: Seattle
Posts: 970
Bikes: Giant Defy 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
#317
Boom.
Join Date: May 2010
Location: Pittsburgh -> Cleveland -> San Francisco
Posts: 2,523
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
I was getting this lovely error:
java.lang.NoSuchMethodError: main
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at edu.rice.cs.dynamicjava.symbol.JavaClass$JavaConstructor.evaluate(JavaClass.java:298)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.handleConstructor(ExpressionEvaluator.java:1 28)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.visit(ExpressionEvaluator.java:98)
at koala.dynamicjava.tree.SimpleAllocation.acceptVisitor(SimpleAllocation.java:137)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.value(ExpressionEvaluator.java:38)
But I couldn't figure out what it was.
java.lang.NoSuchMethodError: main
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at edu.rice.cs.dynamicjava.symbol.JavaClass$JavaConstructor.evaluate(JavaClass.java:298)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.handleConstructor(ExpressionEvaluator.java:1 28)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.visit(ExpressionEvaluator.java:98)
at koala.dynamicjava.tree.SimpleAllocation.acceptVisitor(SimpleAllocation.java:137)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.value(ExpressionEvaluator.java:38)
But I couldn't figure out what it was.
#318
Making a kilometer blurry
My brother is a high end programmer. I asked him about the 2-3 other high end guys at my old job (he is still there). He said that all programmers think their code is better than another "equal" programmer's code.
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
There's also the whole thing with bugs. "It's not a bug, it's a feature."
There was one guy that would razz everyone else on their bugs. When he had a bug he'd quickly add a feature so he could re-release the package with a feature update rather than a bug fix. I forget the way the package naming stuff worked but it was like version.feature.something.bug. So 1.1.2.0 meant 1st version, 1st feature, 2nd something, and no bugs. The one guy would carefully re-release his stuff so the last digit was always zero.
Question is how perfect should you make it. If you make it absolutely bug free it could take too much time (inefficient). If you release things too quickly it'll be buggy (inefficient).
My bro said there were one or two programmers (apparently well known to him but total strangers the other way) who wrote basically bug-free stuff efficiently. He'd talk about them with a lot of respect, kind of like bike racers saying, "Yeah, Voigt is pretty tough".
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
There's also the whole thing with bugs. "It's not a bug, it's a feature."
There was one guy that would razz everyone else on their bugs. When he had a bug he'd quickly add a feature so he could re-release the package with a feature update rather than a bug fix. I forget the way the package naming stuff worked but it was like version.feature.something.bug. So 1.1.2.0 meant 1st version, 1st feature, 2nd something, and no bugs. The one guy would carefully re-release his stuff so the last digit was always zero.
Question is how perfect should you make it. If you make it absolutely bug free it could take too much time (inefficient). If you release things too quickly it'll be buggy (inefficient).
My bro said there were one or two programmers (apparently well known to him but total strangers the other way) who wrote basically bug-free stuff efficiently. He'd talk about them with a lot of respect, kind of like bike racers saying, "Yeah, Voigt is pretty tough".
#319
Senior Member
Join Date: Sep 2008
Location: Murrieta, CA
Posts: 1,035
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
#320
Senior Member
Join Date: Sep 2008
Location: Murrieta, CA
Posts: 1,035
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
My brother is a high end programmer. I asked him about the 2-3 other high end guys at my old job (he is still there). He said that all programmers think their code is better than another "equal" programmer's code.
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
I've always taken the approach that I am only the first of many people who is going to work with this code. So I work very hard at starting with a solid object oriented design. I then code in way that is very clear & straightforward with plenty of short comments. This results in code that is easy to read & follow but not the most efficient. If some inefficient code is affecting the user experience I'll spend some extra time on that piece.
#321
**** that
Join Date: Dec 2006
Location: CALI
Posts: 15,402
Mentioned: 151 Post(s)
Tagged: 0 Thread(s)
Quoted: 1099 Post(s)
Liked 104 Times
in
30 Posts
+1 one of the hardest parts about shipping a major product is deciding which bugs you'll have to live with, and which features you'll have to live without.
#322
Senior Member
"Basically" bug free doesn't mean bug free. But essentially very well written code. Folks compare it to the code that handles internet traffic.
I've lost touch with prod issues where I used to work but the software is very mature, written by the company head in 1987? (whenever banks could trade and brokers could bank) and developed from there for one of the banks (who wanted to trade). All in C, all following pretty rigid standards. As a programmer you can rely on the fact that everything will be treated the same (format, comments, etc).
Although I won't say it's bug free, especially the quick client-request-filling stuff, the basic structure is extremely, extremely robust. When I left in Dec 2007 the infrastructure could update in real time (sub millisecond) prices of 1.5 million instruments, about 275k messages a second (average load was 60-90k messages/sec at busy times in 2006, increasing from 15-40k/sec in 2003), from various feeds using at most 16 2.8 Ghz dual core Intel CPUs (I forget cache levels but they were high - 32 MB?), i.e. 4 quad CPU boxes. Relatively cheap boxes, $8-10k a box, none of those exotic F-15 96 CPU boxes (they used a bunch of those boxes to replace our system and that's when I lost my support job).
Our system could execute algorithmic trades in about 600-800 microseconds (0.8 milliseconds, not sure of what caused the wide range of time - that's about when I left) based on the feed. One of the limiting factors was distance to the exchange so we'd have machines in data centers in the same building as the exchange when possible (mainly for futures). Although I no longer work there I'm very proud of the company and the software produced there. I rarely dealt with bug issues (don't remember any), more things like hardware, network, or user errors.
Anyway my brother is one of the 4 guys that write the serious code (original guy, another senior guy, and another senior guy). The guy that hated bugs is one of them (quick, creative, buggy). Another was one of the original developers, probably the best in the company (according to my bro). Slow, methodical, and pristine, he'd work 3-4 months a year and crank out insane stuff. Boss/owner was original also, he was quick, creative, but didn't do much actual coding. My brother was a combination - he could be quick, he was more methodical than the first guy, and quickly owned up to any issues.
Everyone else is more GUI and feature-related stuff. For actual things like trading engines... it'd be one of those four guys. When he says "Oh, that programmer is really good" it's significant to me. The guy that wrote DOOM (id software) is one guy that my bro admires.
I can't code worth a subroutine. I supported the systems. As a relatively experienced support person, I was happy that we rarely dealt with our own issues. It's very unusual based on my experience at other companies (where a lot of issues were because of whoever I worked for). Most of the prod issues were with the client (hardware, wrong inputs, bad algorithm, etc).
Ah well. Another life that's passed me by.
cdr
I've lost touch with prod issues where I used to work but the software is very mature, written by the company head in 1987? (whenever banks could trade and brokers could bank) and developed from there for one of the banks (who wanted to trade). All in C, all following pretty rigid standards. As a programmer you can rely on the fact that everything will be treated the same (format, comments, etc).
Although I won't say it's bug free, especially the quick client-request-filling stuff, the basic structure is extremely, extremely robust. When I left in Dec 2007 the infrastructure could update in real time (sub millisecond) prices of 1.5 million instruments, about 275k messages a second (average load was 60-90k messages/sec at busy times in 2006, increasing from 15-40k/sec in 2003), from various feeds using at most 16 2.8 Ghz dual core Intel CPUs (I forget cache levels but they were high - 32 MB?), i.e. 4 quad CPU boxes. Relatively cheap boxes, $8-10k a box, none of those exotic F-15 96 CPU boxes (they used a bunch of those boxes to replace our system and that's when I lost my support job).
Our system could execute algorithmic trades in about 600-800 microseconds (0.8 milliseconds, not sure of what caused the wide range of time - that's about when I left) based on the feed. One of the limiting factors was distance to the exchange so we'd have machines in data centers in the same building as the exchange when possible (mainly for futures). Although I no longer work there I'm very proud of the company and the software produced there. I rarely dealt with bug issues (don't remember any), more things like hardware, network, or user errors.
Anyway my brother is one of the 4 guys that write the serious code (original guy, another senior guy, and another senior guy). The guy that hated bugs is one of them (quick, creative, buggy). Another was one of the original developers, probably the best in the company (according to my bro). Slow, methodical, and pristine, he'd work 3-4 months a year and crank out insane stuff. Boss/owner was original also, he was quick, creative, but didn't do much actual coding. My brother was a combination - he could be quick, he was more methodical than the first guy, and quickly owned up to any issues.
Everyone else is more GUI and feature-related stuff. For actual things like trading engines... it'd be one of those four guys. When he says "Oh, that programmer is really good" it's significant to me. The guy that wrote DOOM (id software) is one guy that my bro admires.
I can't code worth a subroutine. I supported the systems. As a relatively experienced support person, I was happy that we rarely dealt with our own issues. It's very unusual based on my experience at other companies (where a lot of issues were because of whoever I worked for). Most of the prod issues were with the client (hardware, wrong inputs, bad algorithm, etc).
Ah well. Another life that's passed me by.
cdr
#323
negligent.
Join Date: Aug 2005
Location: White Plains, NY
Posts: 837
Bikes: a few
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
whoa, you're speakin' my language dude. i suppose i work on a competitor's product, though funnily enough i joined my department just a couple of months before you left yours.
you might be shocked (or not) to see the avg/peak throughputs feeds are pushing now. OPRA expects to hit spikes of 4 million msgs/sec soon, which is well over what can realistically be handled by a single gigabit ethernet line and that's before line arbitration. they split across multiple channels of course (24?), but it's still an astounding rate. and anyone who can actually handle that on a single box gets bragging rights..
oh, and latency expectations have gotten quite a bit lower too
you might be shocked (or not) to see the avg/peak throughputs feeds are pushing now. OPRA expects to hit spikes of 4 million msgs/sec soon, which is well over what can realistically be handled by a single gigabit ethernet line and that's before line arbitration. they split across multiple channels of course (24?), but it's still an astounding rate. and anyone who can actually handle that on a single box gets bragging rights..
oh, and latency expectations have gotten quite a bit lower too
#324
negligent.
Join Date: Aug 2005
Location: White Plains, NY
Posts: 837
Bikes: a few
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Likes: 0
Liked 0 Times
in
0 Posts
I've lost touch with prod issues where I used to work but the software is very mature, written by the company head in 1987? (whenever banks could trade and brokers could bank) and developed from there for one of the banks (who wanted to trade). All in C, all following pretty rigid standards. As a programmer you can rely on the fact that everything will be treated the same (format, comments, etc).
#325
Senior Member
heh. I think you may work with some of the newer clients. The old client was, let's say, a blue blood type of place.
4 mil/sec is waaay over the infrastructure that I left behind. Way way way. No frickin' way way. We'd have to subscribe to selective instruments at that point or deal with some significant lag. I remember meetings where we were discussing OPRA rates. Everyone was looking at each other glumly. We were very proud of the fact that we could subscribe to everything, and going over our capacity would mean that we couldn't do that anymore. It was very depressing. I suppose parallel feeds with different data streams going into one massive infrastructure would work. Fiber lines to/from the exchange would help too, esp if you can locate the data center right next to the exchange's data center.
We were a middleware provider for a big bank until said bank got rid of all middleware providers (there were 2 significant ones, us and someone else). I supported the infrastructure in said big bank. Ironically since I had relatively high level access in the client's systems (in order to get clearances to perform support etc they put me into various groups) I had access to a lot of the plans to get rid of the middleware providers. I highly doubt it was intentional. It helped to see the writing on the wall though - the power point presentations on their exact plans were pretty fascinating.
There are other clients now but they're errr not quite as much under public scrutiny as a big bank.
I just remembered that we had free soda and snacks. When it was quiet I'd go help get the candy/chips - a full shopping cart worth, a couple hundred bucks, for 15 or so people. But our office wasn't really special and the break room wasn't fancy. We just had a ton of junk food.
4 mil/sec is waaay over the infrastructure that I left behind. Way way way. No frickin' way way. We'd have to subscribe to selective instruments at that point or deal with some significant lag. I remember meetings where we were discussing OPRA rates. Everyone was looking at each other glumly. We were very proud of the fact that we could subscribe to everything, and going over our capacity would mean that we couldn't do that anymore. It was very depressing. I suppose parallel feeds with different data streams going into one massive infrastructure would work. Fiber lines to/from the exchange would help too, esp if you can locate the data center right next to the exchange's data center.
We were a middleware provider for a big bank until said bank got rid of all middleware providers (there were 2 significant ones, us and someone else). I supported the infrastructure in said big bank. Ironically since I had relatively high level access in the client's systems (in order to get clearances to perform support etc they put me into various groups) I had access to a lot of the plans to get rid of the middleware providers. I highly doubt it was intentional. It helped to see the writing on the wall though - the power point presentations on their exact plans were pretty fascinating.
There are other clients now but they're errr not quite as much under public scrutiny as a big bank.
I just remembered that we had free soda and snacks. When it was quiet I'd go help get the candy/chips - a full shopping cart worth, a couple hundred bucks, for 15 or so people. But our office wasn't really special and the break room wasn't fancy. We just had a ton of junk food.