Don't confuse your specialized knowledge with common knowledge. Your phrasing assumes that encryption, as a word, conjures up images as it would in a geek's mind (and more than five years earlier than now, when it was less well known.)
Adding to that comment.
One of the attributes of a good IT professional is the ability to speak to non-IT professionals in a language they can understand. That requires learning to translate geakspeak to commonspeak on the fly. If one isn't able to master that, they generally don't progress in the organization because usually the people who make those promotion decisions are not technology people.
I find the LOTR characters "shallow" and undeveloped.
That wasn't the goal of LOTR. It was an epic. Epics (and odyssey's) are usually shallow on character development, but big in scope. That's the nature of novel writing because it's a trade-off between close up character stories, which tend to be narrowly focused time-wise, and large scale fantasy universes spanning decades in novel time. You can't have both and still have a relatively small number of volumes. The Harry Potter series are weak on character development, but no one complains about that.
However, in C, writing memory management only needs to be done once; while writing the "logic for the[ir] application" is done many times. Consequently, the apparent load of writing memory management is much lighter than one might initially recognize. Or to put it another way, once it's done, it's done and represents no load at all.
I don't believe that is true at all. One huge reason for building a memory management scheme is to tailor it to a specific algorithm, which is bound to a particular application. Optimization for allocating small chunks (bytes to kilobytes) can be very different compared to allocating extremely large chunks (megabytes to gigabytes), or variable sized versus fixed size, or read/writes with sequential access versus random access, or low access frequency versus high access frequency, or multi-threaded versus serial. These are all intricately bound to the overall application algorithm and can yield extremely different solutions given a particular problem. It's simply not possible to write a general allocation scheme that is fully optimized for every type of problem. I've experienced this in real world projects.
Another thing: Depending on an external agency to manage your resources is a two-edged sword. If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target.
It's rare that the original developer stays on the project for its lifetime of usage. In fact, I've never seen that happen. People quit, get fired, get promoted, or move onto new projects. When the sole hot-shot in the organization writes a complex codebase, it places a future burden on the lesser experienced team that may inherit it. Maintenance is always more expensive than original development.
If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target... [CUT]... I have huge confidence in it, but, should it turn out to be broken... I could fix it in minutes
I don't believe that for a second. I've seen sneaky bugs in C code plague development teams for days and on a few occasions a week. You're either vastly underestimating or are totally unaware of very well hidden bugs in your code.
But the funny thing is, if you take an app that was designed to run at adequate speed on hardware from, say, 1992, keep the technology behind the app the same if you update it - that is, keep writing efficient C and so on - then the increase in memory and CPU resources serve to turn the app into some kind of blistering miracle implementation instead of the run of the mill performance you get from depending on the latest and greatest HLL with garbage collection
99+% of the time with general problems, I/O is the bottleneck. For those cases, a C application might run 1% faster on newer hardware, given equivalent I/O hardware (same model/make of drive or network). In the vast majority of cases, the effort is simply not worth it. It's far more expensive to pay your salary to build and maintain that codebase than it is to simply purchase a beefier machine. The former is a repeating expense, the latter is a one time expense. Business managers love the latter, not the former.
I do agree that if your domain consists of highly CPU bound computational algorithms that don't require frequent HD or network access, then your approach will scale well with the faster hardware.; however, I don't think advocating it as a baseline approach for all or most projects makes any sense. It is far more work and causes more maintenance headaches than you're describing.
It's really hard to believe that it costs more to produce a CD than it does to produce a DVD when movies cost a hell of a lot more to make.
I had often wondered that: how DVDs could sell for less than CDs despite the fact movie production can cost hundreds of millions versus $1 million for a CD. Well, I think both have extremely different revenue models. People pay to watch a movie played back on the screen, but they don't do the same for a CD. With music they expect live performances, not play back. So instead of 1 band playing 1 venue at any given time, a movie plays in thousands of venues simultaneously. I also believe a far larger portion of the movie revenue from theaters goes back to the production company when compared to revenue from an artist's performance.
Seriously, market a product as "stylish", "hip" and "different", and you'll raise a troupe of people to whom presenting themselves as different is pretty much their only end.
...because we all desire at birth to blend in, be unnoticed, and indulge in the colorless, emotionless, and dreariness of the human experience. What a miserable existence--IMO. Life is better in color.
I personally find it one of the most disgusting facets of consumerist capitalism.
And do you find upgrading your desktop every time a new fang dangled CPU comes out to be a disgusting facet of consumerist capitalism? How about your home? Your car? Your wardrobe? Are you going to say everything you own and wear is square, plain, and vanilla?
It seems to me this might make DC more viable as a power source. Anyone know if it would? It also strikes me as a green energy saving technology that would dramatically drive down the cost of electricity over power lines. I believe a lot of energy is lost due to resistance.
the paradigm is precisely the same just the appliance you are using.
It is not. With a phone you must stop what you're doing and answer it immediately. With an IM, you can let it pend for several minutes when you've got a chance to answer it. For example, you're writing an email and you get an IM. You can finish your email rather be interrupted. An IM is far less intrusive and interruptive than a phone call.
Tech support happens over a dedicated phone number... useful if your computer can't get online:P
Not all tech support is for the LAN. It's becoming quite common for tech support to offer support over IM. We often got colo and database support through IM. It's easier to message someone rather than play phone tag. They also appreciate not being interrupted constantly by ringing phones.
But since the apocalyptic scenario has been brought up: what a great illustration of the fact that we have WAY too much of our food crops being grown as huge tracts of monoculture, often all the same crop and all the same species. What a great target for famine-causing organisms.
And what prevents them from switching crops on 12 months notice? They do it based on market fluctuation. For example, if soy is fetching more profit than wheat, they will switch. I'm not worried about single crop failures. A bigger worry is with general failures with all crops due to soil conditions, such as sterilization, overuse, erosion, or pollution.
Also, what else could we grow? USA and Canada are not rain-forest nations that can grow a wide variety of tropical plants. We are limited to specific crops by our seasons. Although growing a plant that thrives in a tropical climate in Kansas is possible, the effort and energy required to do so on a massive scale would yield negative returns. It's not an accident that corn, wheat, potatoes, and soy are stables in USA. It's due to our climate and what crops are optimal for it.
And lastly. We don't grow 1 species of wheat, 1 species of corn, 1 species of potato, etc. We have numerous species. Many are crossbred or engineered. Just because there are trends and certain seeds and plants are hot for the day, doesn't mean we aren't flexible.
Ok, I keep hearing this "copyright" defense to replace software patents. But how can you enforce that if someone simply modifies the source code? I'm not trying to troll here, I'm just genuinely curious as to what the specifics to that issue are.
It doesn't have to be an exact bitwise copy to count as copyright infringement. If they modify 25% of your code and leave 75% as is and use it without your permission, they're still in violation of using a substantial portion of your code.
In fact, my last employer had such a case. A former employee took source code for an application and was hired by another corporation who happened to hire him to develop a similar type of application. The programmer essentially copied the files, changed some code to fit the specialized function, and released the compiled binary. When the product was released, our company was suspicious and looked at the compiled executable and found it matched unique data strings occurring in our application. There was a very high probability our source was copied. Upon seeing the evidence, their company settled quickly, paid damages, and removed the product from their lineup.
If the vending machine eats your money, you can always consume the item dispensed, so technically the worst case scenario is a break-even.
That's true. Assuming the machine reads the bill and credits you $100, you could claim your money in the form of candy bars and potato chips; however, it would be at 1.5 to 6 times markup compared to the grocery store or full size packages. You're also forced to consume more than you normally would eat.
Let's say the machine takes the bill and credits you $100. When you can only choose one option, do you press the refund button or buy $100 in product? Do you count up the candy bars to see if there's $100 worth before deciding? Will you know with certainty if the refund button won't work? Maybe the refund button will run out of coins. Maybe it'll roll the bill back out. Maybe pressing it will do nothing allowing you to fall back to purchasing the candy bars.
ll see that the "infinite $100 bill trick" works by hitting a sequence, and then asking for your $100 bill back.
And he mentioned vending machines... not slot machines. You can always cash out of a slot machine so of course there's no risk. Not so with a vending machine which may be limited by the amount of money it can refund due to not having enough quarters or having a bug in the programming, which is not much a stretch if one is already hypothesizing that a similar bill processing bug may exist in vending machines.
Makes me miss the good ol' days when you didn't need a staff of hundreds and a multi-million dollar budget to make a good game. Back then one guy who didn't know anything could sit down and within a few months crank out a fun game for a popular console.
You know. Except for the gaming part, exactly that happened with general application programming and the VB/JS/PHP programmers of the 90's and 00's and a lot of people complained that untrained, know nothing dolts were diluting the talent base and bringing down the perceived value of classically educated computer science graduates. For some reason if on the job training occurs with ASM it's romanticized, but if it's high level scripting, it's denigrated.
I took a semester of assembly for CS and it's not that bad, wrote a tic-tac-toe game as a final project where the computer randomly placed it's pieces (could have had it scan the board but that'd be too hard for players, as-is the PC wins most the time) so I know a tiny fraction of what the author's talking about.
ASM is rather fun if the project is small. It's just about the closest you can get to pure, refined coding.
I dunno if your strategy will hold in the continental European context. I'll look into it nevertheless.
It is basically using the business as a front for self-education; however, I do treat my home business very seriously. I maintain detailed accounting records. I intend to try to find ways to generate revenue from it, although I have not been successful yet.
When I go into my next interview, I will start out by saying the work was contract work. I will of course, omit a few pertinent details, such as the fact I owned the business. When questioned further, I'll fess up and say it was a corporation I founded. I will pine away on the vision I had, then wrote a business plan for it, and founded the business to execute that plan. I think all of that sounds pretty adventurous and self-starter-ish. If then questioned further, I will say I was unsuccessful in procuring investment funds so the corporation and/or technology I developed is up for sale. Something like that.
Alas, when applying for a job, they only look at your(professional) experience... Anything done at home in your spare time doesn't count. It's sad:-(
Just register a domain name and then a DBA, LLC, or corporation (take your pick, DBA and sole prop is the cheapest) and do your side projects under your business. Even if your business has negative profits (a great tax deduction), which it probably will if your projects are just for learning or fun, but you could claim your hobby experience as professional experience because it was "contract" work for your biz. You would have the business looking website to prove it. Heh.
It's what I've done, but I have yet to prove the concept. It'll be tested soon tho.:D
Slashdot Mirror
One of the attributes of a good IT professional is the ability to speak to non-IT professionals in a language they can understand. That requires learning to translate geakspeak to commonspeak on the fly. If one isn't able to master that, they generally don't progress in the organization because usually the people who make those promotion decisions are not technology people.
I do agree that if your domain consists of highly CPU bound computational algorithms that don't require frequent HD or network access, then your approach will scale well with the faster hardware.; however, I don't think advocating it as a baseline approach for all or most projects makes any sense. It is far more work and causes more maintenance headaches than you're describing.
The thing is no one ever said customer support would be easy. Expecting that is an unrealistic expectation. Humans are fickle creatures.
If one finds customer support not worth doing, then they shouldn't do it. There are quite a number of career options to choose from.
Everyone started out as a newbie.
http://en.wikipedia.org/wiki/KITT
And do you find upgrading your desktop every time a new fang dangled CPU comes out to be a disgusting facet of consumerist capitalism? How about your home? Your car? Your wardrobe? Are you going to say everything you own and wear is square, plain, and vanilla?
Maybe being different scares you.
...with respect to the AC versus DC issue with power lines. http://en.wikipedia.org/wiki/War_of_Currents
It seems to me this might make DC more viable as a power source. Anyone know if it would? It also strikes me as a green energy saving technology that would dramatically drive down the cost of electricity over power lines. I believe a lot of energy is lost due to resistance.
Also, what else could we grow? USA and Canada are not rain-forest nations that can grow a wide variety of tropical plants. We are limited to specific crops by our seasons. Although growing a plant that thrives in a tropical climate in Kansas is possible, the effort and energy required to do so on a massive scale would yield negative returns. It's not an accident that corn, wheat, potatoes, and soy are stables in USA. It's due to our climate and what crops are optimal for it.
And lastly. We don't grow 1 species of wheat, 1 species of corn, 1 species of potato, etc. We have numerous species. Many are crossbred or engineered. Just because there are trends and certain seeds and plants are hot for the day, doesn't mean we aren't flexible.
In fact, my last employer had such a case. A former employee took source code for an application and was hired by another corporation who happened to hire him to develop a similar type of application. The programmer essentially copied the files, changed some code to fit the specialized function, and released the compiled binary. When the product was released, our company was suspicious and looked at the compiled executable and found it matched unique data strings occurring in our application. There was a very high probability our source was copied. Upon seeing the evidence, their company settled quickly, paid damages, and removed the product from their lineup.
That's true. Assuming the machine reads the bill and credits you $100, you could claim your money in the form of candy bars and potato chips; however, it would be at 1.5 to 6 times markup compared to the grocery store or full size packages. You're also forced to consume more than you normally would eat.
Let's say the machine takes the bill and credits you $100. When you can only choose one option, do you press the refund button or buy $100 in product? Do you count up the candy bars to see if there's $100 worth before deciding? Will you know with certainty if the refund button won't work? Maybe the refund button will run out of coins. Maybe it'll roll the bill back out. Maybe pressing it will do nothing allowing you to fall back to purchasing the candy bars.
Sounds like a math problem.
ASM is rather fun if the project is small. It's just about the closest you can get to pure, refined coding.
When I go into my next interview, I will start out by saying the work was contract work. I will of course, omit a few pertinent details, such as the fact I owned the business. When questioned further, I'll fess up and say it was a corporation I founded. I will pine away on the vision I had, then wrote a business plan for it, and founded the business to execute that plan. I think all of that sounds pretty adventurous and self-starter-ish. If then questioned further, I will say I was unsuccessful in procuring investment funds so the corporation and/or technology I developed is up for sale. Something like that.
Sounds good to me.. heh. heh.
It's what I've done, but I have yet to prove the concept. It'll be tested soon tho.