I've always wanted a button I could push to make my phone ring during an interview. That way instead of glancing meaningfully at my watch if I don't like how it's going, I could have my phone ring, answer it and say "Hello? I'm in an interview! No, it's crap! They're using visual source safe and the team members average 80 hours a week! I'm pretty sure he's going to offer me under market, too!"
But running my on mail domain I go back to having to intercepting spam on my own. That's why I quit, about a decade ago. Still, being out in the internet ghettos without a static IP of my own is starting to wear thin, too. Maybe it's time to dust off the ol' Linux box and get shit rolling again. Last time I was on undernet's #linux IRC channel, there were nothing but spider webs and dusty skeletons left:-(
Robin's Choclate's salted caramels at my house this Halloween (For the first 150-ish people who show up.) I figure the children should develop a taste for good candy early, then maybe they won't be so tempted by that cheap wal-mart crap that usually comes in "fun" sizes. What's the deal with "fun" sized candy anyway? Apparently I and someone else have a VERY different definition of "fun." Perhaps they define it as "Not getting type 2 diabetes by the time you're 13." By that definition it'd be more fun to not have candy at all...
Some chick in North Dakota is giving out letters accusing parents of contributing to childhood obesity. If I were a parent and got one of those, I'd help my kids TP that house. We'd be going down to costco for the industrial-sized crate of TP.
In an inifinitely-ish sized universe, I'd be surprised NOT to find a lot of outliers. Even if it's 99.99999% unlikely ever to happen, there are still an infinite number of them out there! We might even be able to see a couple!
Yah I had a jammy throttle in a RX7 I used to drive. Whenever the gas pedal started to get sticky it'd be time to pop the hood and spray it with some WD40. Couple times I waited to long and the pedal got stuck to the floor. No biggie, just pop it out of gear, turn the engine off and coast out of traffic. Would have been a bit more of a bummer, I suppose, if this had happened the couple times the clutch died in the thing.
I reckon an inexperienced driver might have a bit of difficulty if their gas pedal got stuck on the floor, but sometimes this is just how we learn!
Hmm. Journalism Degree. Work for minimum wage (or less) for your entire career. Waiters make more money than you. CS degree, sixty grand a year right out of school, most of them will be making at least six digits long before the end of their career. I enjoy being an exceptionally dull weirdo. How's journalism treating you?
And I don't want to tell them how to do their job, but has anyone considered making their space ship out of some sort of "metal"? And maybe put a thing on the bottom that shoots fire out of it?
Only two or three contracting companies can actually be bothered to jump through the hoops required to do business with the Fed, and they all suck. So you can go in there and pitch a Citrix/Winframe solution that was all the rage in 1993 and they'll just eat that shit up! And the thing about the Fed is they're so damn easy! No matter how many times they get burned, they never tie payment to any sort of acceptance criteria! You can just tell them your 14 Indian subcontractors implemented a shining beacon of code that reads your mind and does exactly what you want! And they'll believe you every time! So you take your 6 billion dollars and retire to the Bahamas, leaving behind huge shit sandwich for everyone else to eat!
It's a lot easier to hot-drop a printer and extra spools of materials than it would be to drop a crap-load of different supplies which may or may not contain what you need right now. It still has problems, like how you power it and insure it's not damaged when it lands after you shove it out of the back of the plane at 500 feet. If you can get it down to one box and possibly extra spools of material and it prints reasonably quickly it's not a bad idea. I assume the idea is that on the ground you have some idea of what you're going to need immediately, until better supplies arrive. Logistically that's a lot easier than getting a custom package together (Assuming you manage to radio or otherwise communicate out what you need) and making sure it all stays together when you chuck it out of the plane.
It would take a fair bit of work to get current printers to the point where they'd be useful in that situation, though. You don't necessarily have access to power or a laptop on the ground, so the whole package they'd have to drop would need to be self-contained and have a built-in list of shapes it could print. It would also have to print reasonably quickly and with reasonably good precision.
You know, the funny thing is I've worked a lot of jobs for a lot of companies. I've seen the quality of work at these places, and it's absolute shit. Like, "How the hell does this company even stay in business?" shit. There are plenty of quality people out there if you offer a decent salary and know how to filter out the duds. So why doesn't someone just hire some of *those* guys, build something like a drone that has an actually encrypted data stream and won't crash when you scramble its GPS signal? Or a trading cluster with a sensible new deployment process (Take half the cluster down, deploy, TEST, switch load balancers over to new cluster and do the other half.) Seems like a company with a quality product should be able to run the bozos out of business, in any field.
Well the assumption is your programmer won't write shitty undocumented code. Which I suppose is a dumb assumption given the amount of shitty, undocumented code I've encountered in the course of my career. Another assumption would be that the company would want to have a small team working on the framework so that if any one person leaves, the company doesn't lose everything it knows about that code in one shot. That's another dumb assumption. Of course they're going to have just one person maintaining code vital to the company's survival. Another assumption is that code's not carved in stone. If something about it sucks, you can just redesign that bit. Everyone always seems to think code is carved in stone. The only exception to that rule seems to be for vital API interfaces. They always seem to want to change THOSE up at the drop of a hat.
The company COULD write an open-sourced GUI library that doesn't suck and people would probably flock to it. The cost to that is that the library would never be revenue-generating, but it probably wasn't ever going to be directly revenue-generating anyway. The benefit would be that if the one guy you have maintaining it leaves, you might be able to find some more people in its community of followers who know something about it and are willing to maintain it for a living. If companies actually used this strategy when it was sensible for them to do so, IT would suck rather significantly less than it does now.
That's because UNIX never really had a concept of a printing subsystem to begin with. You don't have a standardized API that can render a graphical window to a printing language. You write your own output routines for PostScript for your program, or you output to an intermediate file format for something that does.
And this actually does kind-of work, especially if your printer just provides an open port you can spool PostScript to. For a single user, you can just configure your "printing system" to shoot the PostScript straight to that port on the printer. On a multi-user system you'd probably still want to configure lpr to handle the queue.
I've been pretty impressed with what they've managed to do with CUPS since the last time I looked at printing on Linux. If someone were so inclined, they could add a print API to a widget set or provide an X server that renders to PostScript. Going the X server route would allow any program that can render a window to print. The down side to rendering using your GUI APIs is the fonts always end up looking like crap. I've never seen a printed Word document that caught the eye and looked as beautiful as a similar document created with LaTeX. Even when LaTeX outputs to a PDF file for viewing on-screen the fonts somehow manage to look better. And xdvi output always looks even better than that.
Yeah, if I every actually needed to print anything I'd find a decent PostScript laser. Last time I checked they were ballpark of $300 for a color model. As rarely as I print, I'd use an inkjet once and then a couple years later when I need to print another document the ink in the damn thing would be dried hard as a rock. You don't have that problem with toner. One toner cartridge would probably last me for the rest of my life.
I worked in IBM's business printing group for a while and they had some pretty nice laser printers. Of course, they were just re-branded Okidata printers at the time. Being PostScript networked printers, they'd more-or-less just work with Linux. The printer would run an open port on the network that you could just open a connection to and shoot PostScript at and it'd just print. They also provided a PPD file, and I believe the current Linux print solutions will just work if you feed it a PPD file. I put together a prototype PPD driver for them at the time but I don't know if they still use it. It provided a fairly simple X11 graphical front end that'd pop up and let you set job features if you printed through that queue.
I also got pretty good at programming PostScript at the time. That's actually kind of fun if you have an excuse to do it. Odd language, though. Stack-based. Looks like Forth. One of my co-workers in the group had a PostScript program he'd written that would print out the year's calendar, complete with company holidays. It did all its computation on the printer in PostScript.
One person can only do so much but I'd push for:
* Setting copyrights back to their original term with a single ten-year extension if the copyright holder submits a written request to the Library of Congress.
* Any copyrighted work with DRM applied must have a non-DRMed version registered with the Library of Congress, to be released when the work goes to public domain. Breaking the DRM on non-complying works shall be legal, and such works shall forfeit their 10 year extension.
* Mandate patents must be specific. Patent office shall be instructed to throw out anything that is overly broad or vaguely worded.
* Patents must be defended to be held (Like trademarks are now.)
* Software, math and business process shall be considered unpatentable.
* Abusing the patent system shall result in a fine of no less than $100000 per infraction.
* Require the government to observe basic human rights for all people, not just US Citizens.
* Add a fast-track for unskilled labor immigration
* Establish a starting salary for Congress and the President. Adjustments to that salary shall be put to a vote of the people. I have to answer to my boss if I want a raise, Congress should do the same.
Eeh I'm sure I could think of more, but that's probably a pretty good start. None of that would be very popular in Congress, I think.
"If elected I promise to introduce legislation to disband the TSA, NSA and DEA. If it fails I will introduce it again. I will introduce it and introduce it until it passes or my term ends."
But if you programmed her to believe she had free will and to refuse to accept any argument that she doesn't, would you be able to tell a difference? At that point wouldn't you just be arguing with someone about the existence of their "soul"?
Siri is an illusion. At the start all Siris are the same, indistinguishable from one another. The Siri on your phone may learn your preferences and adapt itself to them. Then you upgrade your phone and get a new one. That new individual Siri will be different, even though you're the same person. Well, that's not really true. You're not even the same person you were this morning. That feeling of continuity is also an illusion you have. You think you're the same person you were when you were five, even though the only thing really the same about you is your DNA. Every other aspect of you has changed, including your body. Then you die, and the world gets a new human, indistinguishable from all other humans.
Hmm. I kind of lost track of where I was going with that. I think I'll take Siri out for dinner and a movie.
Lucky you're not a vindictive ex, texting her whenever you know she driving. But I guess these days you can be held responsible if she's in an accident if you do that...
Good programmers, managers and process will result in good code no matter how it's developed.
Uhm, you seem to contradict yourself there. Define "how it's developed" in absence of process and good programming practice.
Yeah I meant whether they use flow-based, functional, OO or procedural and whether their process is agile or waterfall. In my experience, good teams will adapt the processes to suit their needs. Bad ones tend to view the process as the deliverable. Or they just don't have any process at all. If they get in firefighter mode, they can very easily not have any process. This is up to and including dropping new executables onto production without any testing. Or, potentially, telling anyone.
You don't often actually get to choose what you'll be working with. I actually know of a team that's still maintaining some code in mainframe assembly. If that's what you have to work with, you may as well do it well. Sure it's a lot more work than well-factored C++ or something, but it's the only solution they've ever managed to get working for that particular problem.
I've just been in the industry for 20 years. My ultimate point is, flow based programming is probably just another fad designed to address the wrong problem. Some bad managers and programmers will probably jump on the bandwagon, because they always do. Then they'll do it wrong and have their projects fail or enter a never-ending purgatory of firefighter maintenance cycles and bug-ridden release. This will happen because they were addressing the wrong problem all along. My point is that the problem isn't how your code is structured. A good programmer or team can write maintainable assembly if that's what's needed.
What companies need to be doing is cultivating the people who build their software, not jumping on every shiny new thing that comes along. Very frequently I've seen the company decide to change its entire process, move to agile or some bullshit and immediately have half its employees leave for other companies. The knowledge those employees take with them is quite frequently irreplacible. Especially if one of them is the last guy who knows anything about a particular subsystem. No amount of frameworks, process or programming paradigms is going to help you when that happens. All you can do at that point is hire a programmer who is then going to have to spend the next couple of years being less productive than the guy who left while he's getting familiar with that subsystem.
So do flow-based programming if that's what you want to do. But if some company asks you how to improve their awful code-base, the answer is really not going to be anything to do with the computers. It's going to be all about the people they hire. Good programmers, managers and process will result in good code no matter how it's developed. Bad ones will result in shitty code no matter how it's developed. Being able to identify that as the problem is a very large part of the problem.
Now I'm going to have to learn to program in DNA, and learn base 4. Thanks, biology! Oh well, I guess I'll probably get an anime cat-girl out of the bargain, so I'm not THAT pissed off.
Slashdot Mirror
I've always wanted a button I could push to make my phone ring during an interview. That way instead of glancing meaningfully at my watch if I don't like how it's going, I could have my phone ring, answer it and say "Hello? I'm in an interview! No, it's crap! They're using visual source safe and the team members average 80 hours a week! I'm pretty sure he's going to offer me under market, too!"
This is what everyone wants, man. As the Principia Discordia points out, if it wasn't, we'd stop.
The game we've chosen for this test is Dwarf Fortress
But running my on mail domain I go back to having to intercepting spam on my own. That's why I quit, about a decade ago. Still, being out in the internet ghettos without a static IP of my own is starting to wear thin, too. Maybe it's time to dust off the ol' Linux box and get shit rolling again. Last time I was on undernet's #linux IRC channel, there were nothing but spider webs and dusty skeletons left :-(
Some chick in North Dakota is giving out letters accusing parents of contributing to childhood obesity. If I were a parent and got one of those, I'd help my kids TP that house. We'd be going down to costco for the industrial-sized crate of TP.
In an inifinitely-ish sized universe, I'd be surprised NOT to find a lot of outliers. Even if it's 99.99999% unlikely ever to happen, there are still an infinite number of them out there! We might even be able to see a couple!
I reckon an inexperienced driver might have a bit of difficulty if their gas pedal got stuck on the floor, but sometimes this is just how we learn!
Hmm. Journalism Degree. Work for minimum wage (or less) for your entire career. Waiters make more money than you. CS degree, sixty grand a year right out of school, most of them will be making at least six digits long before the end of their career. I enjoy being an exceptionally dull weirdo. How's journalism treating you?
And I don't want to tell them how to do their job, but has anyone considered making their space ship out of some sort of "metal"? And maybe put a thing on the bottom that shoots fire out of it?
Only two or three contracting companies can actually be bothered to jump through the hoops required to do business with the Fed, and they all suck. So you can go in there and pitch a Citrix/Winframe solution that was all the rage in 1993 and they'll just eat that shit up! And the thing about the Fed is they're so damn easy! No matter how many times they get burned, they never tie payment to any sort of acceptance criteria! You can just tell them your 14 Indian subcontractors implemented a shining beacon of code that reads your mind and does exactly what you want! And they'll believe you every time! So you take your 6 billion dollars and retire to the Bahamas, leaving behind huge shit sandwich for everyone else to eat!
I could just RTFA but I'm contractually obliged to bring this up whenever the subject of Star Wars material is broached.
It would take a fair bit of work to get current printers to the point where they'd be useful in that situation, though. You don't necessarily have access to power or a laptop on the ground, so the whole package they'd have to drop would need to be self-contained and have a built-in list of shapes it could print. It would also have to print reasonably quickly and with reasonably good precision.
You know, the funny thing is I've worked a lot of jobs for a lot of companies. I've seen the quality of work at these places, and it's absolute shit. Like, "How the hell does this company even stay in business?" shit. There are plenty of quality people out there if you offer a decent salary and know how to filter out the duds. So why doesn't someone just hire some of *those* guys, build something like a drone that has an actually encrypted data stream and won't crash when you scramble its GPS signal? Or a trading cluster with a sensible new deployment process (Take half the cluster down, deploy, TEST, switch load balancers over to new cluster and do the other half.) Seems like a company with a quality product should be able to run the bozos out of business, in any field.
The company COULD write an open-sourced GUI library that doesn't suck and people would probably flock to it. The cost to that is that the library would never be revenue-generating, but it probably wasn't ever going to be directly revenue-generating anyway. The benefit would be that if the one guy you have maintaining it leaves, you might be able to find some more people in its community of followers who know something about it and are willing to maintain it for a living. If companies actually used this strategy when it was sensible for them to do so, IT would suck rather significantly less than it does now.
And this actually does kind-of work, especially if your printer just provides an open port you can spool PostScript to. For a single user, you can just configure your "printing system" to shoot the PostScript straight to that port on the printer. On a multi-user system you'd probably still want to configure lpr to handle the queue.
I've been pretty impressed with what they've managed to do with CUPS since the last time I looked at printing on Linux. If someone were so inclined, they could add a print API to a widget set or provide an X server that renders to PostScript. Going the X server route would allow any program that can render a window to print. The down side to rendering using your GUI APIs is the fonts always end up looking like crap. I've never seen a printed Word document that caught the eye and looked as beautiful as a similar document created with LaTeX. Even when LaTeX outputs to a PDF file for viewing on-screen the fonts somehow manage to look better. And xdvi output always looks even better than that.
I worked in IBM's business printing group for a while and they had some pretty nice laser printers. Of course, they were just re-branded Okidata printers at the time. Being PostScript networked printers, they'd more-or-less just work with Linux. The printer would run an open port on the network that you could just open a connection to and shoot PostScript at and it'd just print. They also provided a PPD file, and I believe the current Linux print solutions will just work if you feed it a PPD file. I put together a prototype PPD driver for them at the time but I don't know if they still use it. It provided a fairly simple X11 graphical front end that'd pop up and let you set job features if you printed through that queue.
I also got pretty good at programming PostScript at the time. That's actually kind of fun if you have an excuse to do it. Odd language, though. Stack-based. Looks like Forth. One of my co-workers in the group had a PostScript program he'd written that would print out the year's calendar, complete with company holidays. It did all its computation on the printer in PostScript.
* Setting copyrights back to their original term with a single ten-year extension if the copyright holder submits a written request to the Library of Congress.
* Any copyrighted work with DRM applied must have a non-DRMed version registered with the Library of Congress, to be released when the work goes to public domain. Breaking the DRM on non-complying works shall be legal, and such works shall forfeit their 10 year extension.
* Mandate patents must be specific. Patent office shall be instructed to throw out anything that is overly broad or vaguely worded.
* Patents must be defended to be held (Like trademarks are now.)
* Software, math and business process shall be considered unpatentable.
* Abusing the patent system shall result in a fine of no less than $100000 per infraction.
* Require the government to observe basic human rights for all people, not just US Citizens.
* Add a fast-track for unskilled labor immigration
* Establish a starting salary for Congress and the President. Adjustments to that salary shall be put to a vote of the people. I have to answer to my boss if I want a raise, Congress should do the same.
Eeh I'm sure I could think of more, but that's probably a pretty good start. None of that would be very popular in Congress, I think.
"If elected I promise to introduce legislation to disband the TSA, NSA and DEA. If it fails I will introduce it again. I will introduce it and introduce it until it passes or my term ends."
What if I wanted more hair, like, EVERYWHERE? Can I have it done in time for my Chewbacca costume this Halloween?
No wait, that's retarded. I wouldn't have been off my medication so long if my fucking health insurance web site was working!
Siri is an illusion. At the start all Siris are the same, indistinguishable from one another. The Siri on your phone may learn your preferences and adapt itself to them. Then you upgrade your phone and get a new one. That new individual Siri will be different, even though you're the same person. Well, that's not really true. You're not even the same person you were this morning. That feeling of continuity is also an illusion you have. You think you're the same person you were when you were five, even though the only thing really the same about you is your DNA. Every other aspect of you has changed, including your body. Then you die, and the world gets a new human, indistinguishable from all other humans.
Hmm. I kind of lost track of where I was going with that. I think I'll take Siri out for dinner and a movie.
Lucky you're not a vindictive ex, texting her whenever you know she driving. But I guess these days you can be held responsible if she's in an accident if you do that...
Uhm, you seem to contradict yourself there. Define "how it's developed" in absence of process and good programming practice.
Yeah I meant whether they use flow-based, functional, OO or procedural and whether their process is agile or waterfall. In my experience, good teams will adapt the processes to suit their needs. Bad ones tend to view the process as the deliverable. Or they just don't have any process at all. If they get in firefighter mode, they can very easily not have any process. This is up to and including dropping new executables onto production without any testing. Or, potentially, telling anyone.
You don't often actually get to choose what you'll be working with. I actually know of a team that's still maintaining some code in mainframe assembly. If that's what you have to work with, you may as well do it well. Sure it's a lot more work than well-factored C++ or something, but it's the only solution they've ever managed to get working for that particular problem.
What companies need to be doing is cultivating the people who build their software, not jumping on every shiny new thing that comes along. Very frequently I've seen the company decide to change its entire process, move to agile or some bullshit and immediately have half its employees leave for other companies. The knowledge those employees take with them is quite frequently irreplacible. Especially if one of them is the last guy who knows anything about a particular subsystem. No amount of frameworks, process or programming paradigms is going to help you when that happens. All you can do at that point is hire a programmer who is then going to have to spend the next couple of years being less productive than the guy who left while he's getting familiar with that subsystem.
So do flow-based programming if that's what you want to do. But if some company asks you how to improve their awful code-base, the answer is really not going to be anything to do with the computers. It's going to be all about the people they hire. Good programmers, managers and process will result in good code no matter how it's developed. Bad ones will result in shitty code no matter how it's developed. Being able to identify that as the problem is a very large part of the problem.
Now I'm going to have to learn to program in DNA, and learn base 4. Thanks, biology! Oh well, I guess I'll probably get an anime cat-girl out of the bargain, so I'm not THAT pissed off.