Do a CRC...AND... an MD5, and use a database. I built an internal file management system for one company that was (at the time) handling only about 1.75 TB of files. I was unpleasantly surprised at the number of duplicate CRCs I got on non-duplicate files. Using two different types of signatures, plus the file sizes alleviated that problem. Once you have it in a database it is also a bit easier to decide which one you want to keep and/or where to keep it by using some query/column value tricks. Flagging the values as duplicates is also trivial. My product was server based with a web services interface to access the files, so I also threw in a compressing/encrypting feature with access by their original path hitting a keyed server file in the back end. It was amazing to me how much faster server file access was when I did endpoint (both server and client) zipping before transfer. I also used the CRC, MD5, and length to avoid unnecessary downloads to begin with.
Another option (not available for Windows, as far as I've seen) is to use a file system that simply dedups each sector, which buys A LOT more disk space than a simple file-level dedup.
You've got to remember that using FOSS software doesn't mean that you aren't going to have an expense for this. One of the downsides of FOSS is that it is generally software that "scratches the itch" of those willing to develop code for it. It doesn't mean that the software is lower quality, just that they may not have covered everything you need. Also, it may not be the easiest thing to install. If you aren't a Linux geek, or you now don't have time to be since you are running a restaurant, make sure you have some competent local support lined up. Proper install, setup, and security is important and can't just be swept under the rug.
Also, another somewhat obvious suggestion is to make sure you can line up an accountant that is familiar (or willing to become so) with the software you choose for the books. If you find one that actually uses some FOSS, they would have better advice on what packages to use, since they are more familiar with the accounting/regulations side of things.
Be aware that regional corporate and finance laws may be different than those of the software developers'. Commercial software has a general business requirement to keep up with those and supply the necessary patches. In absence of the commercial incentive to "not get sued over missing a patch" you will need to make sure that you have that covered. A few dollars of support to a local programmer (in conjunction with the aforementioned accountant to keep things moving in the right direction) will keep you out of the legal ditches as well as ACTUALLY support FOSS software.
In general, there is a price to pay for freedom. There always has been. If you want software that isn't locked up by greedy or laconic software corporations, you can't be greedy either. You still need to pay for the expertise to keep things on track and actually support the free environment that you wish to take advantage of. Costs are still there. They just shift. If you go in with open eyes, it won't shock you. It's still worth the investment. It just takes a slightly thicker skin to (hopefully) get a slightly cheaper and more customized outcome.
I can see it now. 500 petabytes stored on a postage stamp housed in a device the size of an overstuffed, large suitcase. It has geek written all over it! I must have one.!!!
There are those of us who learn and visualize what is around us from a purely conceptual viewpoint. There are others who view things from the point of view of the formulas behind them. Both approaches are correct, just different. One NEEDS to understand "why" while the other NEEDS to understand "how". It is simply how we are wired. It's the dichotomy of the two that have allowed us to reach the heights that we have. This is not an argument that should be ventured, "who is right?" The best option is to understand our own propensities and explore our individual strengths for learning and growth while also reaching across the chasm to those of the different stripe to build that whole picture. It is that collaboration that, more quickly, takes us from theoretical to applied. We can avoid the "religious" disputes of our predecessors by understanding this. A Physicist uses math to find an explanation for what he already sees. A Mathematician discovers physical truths through his math.
Dude, I out rank you by several years. You mind is flexible. It can be retrained to function in ways you have never dreamed before... at any age. It takes a willingness to attack the inflexibility with novel approaches. Listen to different types of music. Work on making music. If you aren't a math wiz dive into Khan Academy and stretch an analytic approach to thinking (go from basic to advanced math as fast as you can.) Run your life different. Start writing books for fun. Learn a new language. (Chinese is a great brain jump starter!)
The point is, you have to choose the level of flexibility for your brain. Remapping patterns (thinking behaviors and assumptions), on a regular basis, teaches your neural network flexibility. It changes the wiring of the neural pathways from "think as a coder" to "think as a learner/creator". Even within the narrow confines of "being a programmer", moving from OOP/imperative programming to functional programming, requires a great deal of brain flexibility. Once you start opening up your ability to learn in new ways, however, you will find that you are no longer limited to a programming (or development manager) career path.
You may be 40 but you are probably not even half over with your life. Keep you brain (and body) active and changing. It will insure an interesting LIFE instead of a limited CAREER.
Gook luck grasshopper.
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
Those who do keep the binaries, partly, because the tool sets change. A patch to the compiler can change the resulting binary. If you have a specific binary in the field that was compiled with one version, you may not be able to duplicate a bug using a binary from a newly patched compiler.
Granted, I don't recommend using a VCS to store all binaries along with the source. That is just asking for trouble. I do, however, store a single "release package" of binaries and other data that relate to a specific source code branch for each officially released version.
This historical reference helps when traditional debugging doesn't work. Sometimes the bug was in the compiler. If you can't isolate the problem to the binary vs. the source code, it can be a nightmare.
It would probably be more efficient to use a traditional file store but using a VCS, if done simply, can be very convenient.
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
Finish your math degree. Go as far as you can go on that. (Doctorate, even...) If you can do the math you can outpace most programmers at their own game. Most programmers, as it is, were not trained in college to program. I was trained in Chemistry.
Basic programming may not look like math but almost anything worthwhile being programmed uses math extensively (even when the programmer doesn't realize it!). Understanding the best way to accomplish something mathematically will make shorter work of programming it. Math may not be "the end all" but it's definitely an essential skill.
Programming languages and concepts are much easier to learn than the math so finish there first. Then get a "math job" that also needs some programming on the side. You'll be able to do the switch easy enough.
It's actually pretty fun. I already transcribed one piece. It's running a bit slow though. When they said "crowd sourcing", I don't think they meant "slashdot crowd sourcing".
Honestly, you may never be able to convince a budget pusher that testing will save money. What they see is a financial constraint that they may not be able to get around. As a coder, however, you can make YOURSELF more valuable by learning test methodology as a way of life. It has changed the way I think and code. My code is cleaner. I now deliver finished and stable product much faster.
First, let's look at the types of testing you may encounter. The most important, and easiest to introduce, is unit testing. Unit testing effects your approach to building clean, reusable modules. The second is regression testing, which is basically just the practice of keeping all your unit tests and running them ALL every time you add a new module or change an existing one. This keeps your bug fixes or functionality from "regressing". The next, if needed, is stress testing. This is important if you have an app that deals with a lot of data or a lot of user traffic. It helps you determine is there might be an issue with the chosen platform, database engine, even your network "pipes" clogging traffic. The last, and hardest to implement, is UI testing. That route usually requires a set of libraries that compile into your app. There aren't a lot of good ones out there, but the are some new stars rising in the field.
Let's get to the most important one now, unit testing. Unit testing, for a lot of languages can be implemented free and incrementally, which is how I started. If you are running C#, look into NUnit or even Microsoft's testing suite, built into pro versions of VS 2005 or greater. If C++, look at CppUnit. For Java, there is JUnit. If you are using SmallTalk (not very likely) there is the granddaddy of unit testing, SUnit, from which the rest derived. Even Flex and Flash from Adobe has FlexUnit. These are all free (or included in the development tools.) There are other projects out there for other languages but you'll have to research that yourself.
If you have never done unit testing get a book or three on Test Driven Development. It's a pretty large bite to chew, but give it time. This is more about improving your career than fixing a single problem. The basic idea is that, when you start solving a programming problem, break it down into small chunks and write a set of tests that will prove the code for each small chunk. Keep your classes small and focused. This will improve not only testability, but reusability, and inheritability (if those are even words). Don't tie UI code directly to the functionality behind it. This improves testability, but it also makes it easier to change out UI components when a wrong UI decision is corrected. For instance, if you program in a progress bar but the customer wanted a fuel gauge look, the functional code can service the different looks without changing.
Even with unit tested code you will still find bugs. The trick here is to make sure that 1) the classes are small and focused (mentioned earlier), 2) the class (and relevant unit tests) are well documented so that there is no guessing as to why you did what you did, and 3) the unit tests are well organized. When you run into a bug, sometimes just because of bad data in the real world, build a new test that duplicates the condition and fails (throws an error or somesuch), then modify the class(es) to handle the condition. Run that test again to make sure it worked. Then, lastly, run the full suite of tests that you built to see if you brake anything else with your change. This last test (regression testing) is the magic that makes unit testing shine.
I know that this post doesn't directly answer your question, but sometimes, a little understanding goes a long way to helping you ask the right question instead of guessing. Currently, I write about twice as much code as I used to. Half of it is unit tests (maybe more). The quality of my code, however, has greatly improved. I am also able to deliver cleaner code faster. Just like project management, where, if done right, you
For those not too young to remember, Bill Clinton's reelection was guaranteed by the Democrats using the same tactics to get Bob Dole on the Republican ticket. This tactic is distasteful no matter who tries it. What would be intensely hilarious to me would be for Palin to win in 2012 after such meddling. Here's a warning to those Democrats who would stoop to such tactics: She has more support than you think. A true grass roots push coupled with a group of idiots voting outside their party would be enough to tip the pot.
How 'bout instead of being dishonest, people, try to find a better candidate than Obama. If he can't win without subterfuge, he doesn't belong on the ticket. Though legal, this is no more morally sound than the Watergate breakins during the Nixon administration.
The Challenger disaster was a personal tragedy for many of us. The shuttles represented the resurgence of hope that we were experiencing after 2 decades of societal insanity (60s and 70s). If you're too young to remember or not from the US, the whole nation mourned for quite a while. Having a video that you took of the incident would be akin to keeping a memento of a loved one that you just lost, a personal reminder of what was lost.
I've had very similar experiences with pianos. I'm by no means a master. I don't even consider myself proficient, but the opportunities that I have had to play a really excellent piano made things totally different. From the weight of the keys and their responsiveness to my touch to the acoustic quality and shape of the box surrounding the harp, everything sounded and felt different. I've only been "lost" playing piano twice in my life. Once was on a high end traditional full grand (can't remember the make). The other time was, to my surprise, on an simple Yamaha full keyboard (a high-end electric one with only 2 "voices"). It felt and sounded as good as the grand to me. I was shocked that an electronic device could really produce that sound and have such a velvety feel. It was a dream to play.
If instruments with that level of quality were accessible to everyone I believe that the amount of truly inspiring musical compositions would begin to soar. My piano play began to wane after those experiences simply because everything else left me flat. When you truly enjoy the experience of playing a quality instrument and the instrument itself is not fighting against you in the production of a really beautiful sound your creativity level goes way up.
With the studies out that have definitively proven the link between playing music (including singing) and the increase in abilities in language, math, and science aptitude I begin to wonder if more common access to high quality instruments would help to improve the math, science, and language problems we now have in the education system. I would certainly help reduce the amount of pop-noise that pervades our society today.
PI is a formula that describes a relationship of measurements regarding a circle. The problem being that we know imprecisely the results of that formula without knowing the formula. The search for a repetitive pattern (to help define the formula) in the result is, thus far, proving unproductive. I would wager to guess that, at over 2.5T digits, a found repetition will still not help.
Typically, an answer for something this daunting will be far simpler than expected and come from a kid or young adult from the least expected country on the planet.
I look forward to that jaw-dropping, Homer Simpson quoting day.
But I believe if the Egyptians were smart enough to use these plants for recreational use, then they should have been smart enough to cultivate them as well...
"Dude, I think I smoked the last plant......bummer"
Thanks for the review Adrian! I'm also a.Net 2.0 programmer. Being employed doing 2.0 full time makes it hard to bounce around the net trying to find cohesive 3.5 examples and explanations (that aren't just hacks.) This looks like a good place to do the concentrated study that I need.
I was working on NDS when it first came out and AD when it first came out as well. AD was never an x.500 "compliant" directory. It was shoe-horned into semi-compliance. It still suffers from a lot of organizational and management problems because of this. That's not to say that the x.500 (actually x.509) is the best mechanism for organizational object management to begin with. The design suffers from huge limitations.
As of v4.11 of Novell's NDS (now eDirectory), NDS was a far superior system for managing objects. I was easily managing hundreds of servers and thousands of Windows workstations (using Zen Works) with NDS in the NetWare 4.11/4.12 time frame. This included enterprise software roll out, local NT registry management, software and hardware inventory, and on-demand software delivery. I could easily drop in a replacement PC for a user and it would auto-build the software profile for them. We didn't spend hours trying to fix a user's PC if it was hosed or infected. We swapped their old one for a new one. When they logged in they got their old tools and files (network stored). The old PC was diagnosed and wiped at our leisure.
The programming API for NDS was much simpler that for AD (or LDAP, for that matter). The limitation there was having to use the Watcom C compiler to wrap NetWare NLMs (NetWare Loadable Modules. The old 3.x versions were called VAPs - Value Added Processes).
AD still suffers from old holdover problems (like groups not showing up via one API, but visible in another, or simply showing some members and truncating the list, having to know which server to query, etc...)
Novell's NDS was stronger in the 4.11+ days than AD is now. This includes extensibility, manageability, API, etc... That doesn't mean that MS isn't making progress, just that they should have listened to us back in '97 when we were asking them to license NDS from Novell and drop the death-trap that was AD. We would be 11 years farther on stability and usability if they had.
I have no idea how stable or usable NDS/eDirectory is now. Very few shops depend on it now and I had to drop it from my bag of tricks so that I could focus on what paid the bills.
Here's a basic list of MS non-innovation over time:
CPM/MPM instead of MS-DOS: better stability and multi-threading on 8086/8088 hardware
GeoWork Ensemble instead of Windows 3.0: better stability and MUCH better performance under DOS. Great multi-threading! Killed by MS via anti-competitive no-bundle threats to OEMs
NDS instead of AD: better performance, stability, and usability in '97 for NDS than now for AD. We would have been many years ahead of where we are if MS had adopted it.
the list goes on...
Enough ranting... MS is doing better with AD than they were, but it still has a long way to go.
That would be like rebuilding a hurricane flooded city that is below sea level and only protected by weak levies... like that's going to happen!... oh wait....
"I recently graduated from a 'major' university in America with a BS degree in Computer Science. I unfortunately must admit that I am not very skilled with programming.
Unfortunately, many who focused on programming in college also aren't very skilled in programming...
There are many areas to choose from that don't require skills in programming. You should, however, keep yourself versed in understanding how to read a program. It is a necessary skill no matter what area of expertise you choose.
I wouldn't recommend "support" unless you like being attached to a phone or stuck in a dead-end job diagnosing why a PC won't boot. If have any talent in seeing skills in other people or managing a project, I would recommend PMI certification (Project Management). That allows for a clear path to management.
Another good area is QA/Six Sigma type work. If you are good at math and can wrap your head around the metrics of improvement and testing from a quantitative and qualitative framework, this is an excellent and challenging field. There will be some "programming" involved, but usually things like Excel macros and such that relate to statistics. (On a side not: beware of Excel's statistics related functions. Many of them are terminally ill and have been from the beginning. Verify all your data and test multiple scenarios with a handy TI or HP calculator beside the keyboard.)
In almost all IT-related fields the time from expert to out-of-date is around 6 month if you aren't studying. Security work has a shelf life of 1 to 2 months, though. So unless you don't mind intense study for the entire time you are working, stay abreast of security but avoid it as a career. I do have some friends, however, who love the field and have stayed for years. It's more about your disposition than anything.
On the salary basis, don't get too excited. Since you are just starting out, stay light on your bills and choose a targeted path. If you get stuck on too high a standard of living too early, it is almost impossible to switch jobs, if needed, to better align yourself with your career growth plans. In the first 5 to 7 years, expect to switch around a bit to get into the proper career groove. Then, lay down some time in 1 (maybe 2) semi-long-term spots that are challenging and will grow your skills.
Keep an open mind. I have been a bonifide expert in several technologies that became extinct overnight. You can't really predict with any certainty what will and what won't last. Keep up with multiple areas and technologies at once.
Always keep your eyes open for good high-level positions that you can do with a little stretch. Also keep in touch with education. If you have a BA or BS, go for an MS or two. MBAs may be boring but they open doors for you. PhDs are typically overkill and tend to sap the brains and make the decorated individual quite useless in a real-world IT scenario.
Blog smart, publish often, write books. Even if you stink at writing, get good at it (and get a good editor until you are). The published will always get a job.
About "blog smart"... Don't be stupid. Stay out of politics and your personal life. The Myspace/Facebook generation keeps shooting itself in the foot because all their dirty laundry is aired out in the public. As a very unfortunate example, if you like you music edgy (pick the genre) and blog about it, you could lose out on a job interview to someone with less experience and harder music tastes who doesn't blog about it. Corporate hiring wonks are relying more and more on internet research for candidates.
I've been through 24 years in this industry in everything from programming to system admin to security expert, with a lot of things in between. Stay light, even with a family. This can be a feast or famine industry. Keep your possessions liquidable and classically sparse. When the money rolls in, don't spend it all. Sock it away. Invest some. "matress" some
.NET is nice on Windows, definitely. But on Linux, there are so many more alternatives. It's really that.Net is nice...and it can run (as Mono) on Linux. If you are very familiar with a language such as C#, it's oh so much easier to not switch languages when switching OSs. Mono allows this to an extent.
Unfortunately, the.Net 2.0 spec is only just reaching maturity in Mono (WinForms and such...) so most distros don't support a full 2.0 implementation.
The easiest thing for this user to do would be to just install the latest openSuse (a distro that I don't like) and install Mono from their Yast package system. They will keep it the most up to date.
If you ARE familiar enough with linux, get the latest package that goes with your distro straight from the Mono project....or.... for the adventurous, build it from source.
Have fun!
After 24 years of this, the best answer is, "it depends."
The common Black-on-white that is most prevalent these days stinks. The idea is to emulate paper, but with a radiating screen, that's a bad idea. Thus, e-paper.
From the older interfaces, these combinations worked best:
- Bright yellow crisp mono spaced fonts on a dark blue background. This is great for long work hours without sucking your eyes out of the sockets.
- Bright white on dark blue. Same reasons. These two combinations, combined with white or yellow on black for highlights, make a good simple combination.
- For low-light conditions, such as an emap in a car, go with the traditional green on black or amber on black. Amber is prettier but harder to focus on quickly when glancing. Green is definately better. The current mapping systems with bright backgrounds are only good for daytime driving. The brightness of the screen causes temporary night-blindness when glancing back and forth at night.--very dangerous--
- For modern web and client app interfaces, good contrast without major glare is important.
- Bright blues are pretty, but are painful to a large percent of the population when exposed over long periods. It has something to do with the monitor focal point regarding blue light. Ask an expert on this.
- Use semi-bright backgrounds, but not glaring. Muted (not primary) pastels with a crisp font are good. Examples include "dusty" pinks/salmons or dusty greens, yellows, warm blue-grays serve as good majority backgrounds where whites (unless muted) should only be used for highlights.
- You need to make the fonts crisp and readable. Contrast the colors without causing the "spectral blur" that make it look like a "rainbow" on the edges. It may be a cool effect, but it causes eye strain.
- Compliment the colors with the expected environment spectrum. An office typically has cool (read cheep) fluorescent lighting and drab office colors. Use a warmer set here. For a home application, use cooler colors due to the typically warmer environment. The contrast is more appealing.
- Just as you contrast the colors with the environment, compliment the hue and brightness. A bright area should have a bright screen to match where a low light area should have a darker interface to reduce eye strain.
Generally, it takes some practice and a lot of input. Some things are often overlooked. A good example is flashing colors, images, or fonts. Just don't do it. These cause huge eye strain and can even cause epileptic seizures. Layout, also is usually an afterthought. This was just as true back when all computers were dumb terminals attached to a mainframes. Most programmers just stink as designers. Clearly delineated layouts are ***ALMOST*** as important as the color scheme. Remember the old timers' rule of thumb. If a novice computer user who knows nothing of the business background for the application can easily explain to you what the application is for and how to use it, then, and only then, it's a good interface.
...that the actual culprits (of the most recent "oopses") were an employees of a contractor run by an Obama adviser, John O. Brennan. The previous one was a trainee who was instructed to test the access with a family member's name. I'm neither for nor against Obama, but he crowed the loudest and it was people answering to someone in his camp, not from "the administration"....interesting...
Do a CRC ...AND... an MD5, and use a database. I built an internal file management system for one company that was (at the time) handling only about 1.75 TB of files. I was unpleasantly surprised at the number of duplicate CRCs I got on non-duplicate files. Using two different types of signatures, plus the file sizes alleviated that problem. Once you have it in a database it is also a bit easier to decide which one you want to keep and/or where to keep it by using some query/column value tricks. Flagging the values as duplicates is also trivial. My product was server based with a web services interface to access the files, so I also threw in a compressing/encrypting feature with access by their original path hitting a keyed server file in the back end. It was amazing to me how much faster server file access was when I did endpoint (both server and client) zipping before transfer. I also used the CRC, MD5, and length to avoid unnecessary downloads to begin with.
Another option (not available for Windows, as far as I've seen) is to use a file system that simply dedups each sector, which buys A LOT more disk space than a simple file-level dedup.
You've got to remember that using FOSS software doesn't mean that you aren't going to have an expense for this. One of the downsides of FOSS is that it is generally software that "scratches the itch" of those willing to develop code for it. It doesn't mean that the software is lower quality, just that they may not have covered everything you need. Also, it may not be the easiest thing to install. If you aren't a Linux geek, or you now don't have time to be since you are running a restaurant, make sure you have some competent local support lined up. Proper install, setup, and security is important and can't just be swept under the rug.
Also, another somewhat obvious suggestion is to make sure you can line up an accountant that is familiar (or willing to become so) with the software you choose for the books. If you find one that actually uses some FOSS, they would have better advice on what packages to use, since they are more familiar with the accounting/regulations side of things.
Be aware that regional corporate and finance laws may be different than those of the software developers'. Commercial software has a general business requirement to keep up with those and supply the necessary patches. In absence of the commercial incentive to "not get sued over missing a patch" you will need to make sure that you have that covered. A few dollars of support to a local programmer (in conjunction with the aforementioned accountant to keep things moving in the right direction) will keep you out of the legal ditches as well as ACTUALLY support FOSS software.
In general, there is a price to pay for freedom. There always has been. If you want software that isn't locked up by greedy or laconic software corporations, you can't be greedy either. You still need to pay for the expertise to keep things on track and actually support the free environment that you wish to take advantage of. Costs are still there. They just shift. If you go in with open eyes, it won't shock you. It's still worth the investment. It just takes a slightly thicker skin to (hopefully) get a slightly cheaper and more customized outcome.
I can see it now. 500 petabytes stored on a postage stamp housed in a device the size of an overstuffed, large suitcase. It has geek written all over it! I must have one.!!!
There are those of us who learn and visualize what is around us from a purely conceptual viewpoint. There are others who view things from the point of view of the formulas behind them. Both approaches are correct, just different. One NEEDS to understand "why" while the other NEEDS to understand "how". It is simply how we are wired. It's the dichotomy of the two that have allowed us to reach the heights that we have. This is not an argument that should be ventured, "who is right?" The best option is to understand our own propensities and explore our individual strengths for learning and growth while also reaching across the chasm to those of the different stripe to build that whole picture. It is that collaboration that, more quickly, takes us from theoretical to applied. We can avoid the "religious" disputes of our predecessors by understanding this. A Physicist uses math to find an explanation for what he already sees. A Mathematician discovers physical truths through his math.
Dude, I out rank you by several years. You mind is flexible. It can be retrained to function in ways you have never dreamed before... at any age. It takes a willingness to attack the inflexibility with novel approaches. Listen to different types of music. Work on making music. If you aren't a math wiz dive into Khan Academy and stretch an analytic approach to thinking (go from basic to advanced math as fast as you can.) Run your life different. Start writing books for fun. Learn a new language. (Chinese is a great brain jump starter!)
The point is, you have to choose the level of flexibility for your brain. Remapping patterns (thinking behaviors and assumptions), on a regular basis, teaches your neural network flexibility. It changes the wiring of the neural pathways from "think as a coder" to "think as a learner/creator". Even within the narrow confines of "being a programmer", moving from OOP/imperative programming to functional programming, requires a great deal of brain flexibility. Once you start opening up your ability to learn in new ways, however, you will find that you are no longer limited to a programming (or development manager) career path.
You may be 40 but you are probably not even half over with your life. Keep you brain (and body) active and changing. It will insure an interesting LIFE instead of a limited CAREER.
Gook luck grasshopper.
Those who do keep the binaries, partly, because the tool sets change. A patch to the compiler can change the resulting binary. If you have a specific binary in the field that was compiled with one version, you may not be able to duplicate a bug using a binary from a newly patched compiler.
Granted, I don't recommend using a VCS to store all binaries along with the source. That is just asking for trouble. I do, however, store a single "release package" of binaries and other data that relate to a specific source code branch for each officially released version.
This historical reference helps when traditional debugging doesn't work. Sometimes the bug was in the compiler. If you can't isolate the problem to the binary vs. the source code, it can be a nightmare.
It would probably be more efficient to use a traditional file store but using a VCS, if done simply, can be very convenient.
Finish your math degree. Go as far as you can go on that. (Doctorate, even...) If you can do the math you can outpace most programmers at their own game. Most programmers, as it is, were not trained in college to program. I was trained in Chemistry.
Basic programming may not look like math but almost anything worthwhile being programmed uses math extensively (even when the programmer doesn't realize it!). Understanding the best way to accomplish something mathematically will make shorter work of programming it. Math may not be "the end all" but it's definitely an essential skill.
Programming languages and concepts are much easier to learn than the math so finish there first. Then get a "math job" that also needs some programming on the side. You'll be able to do the switch easy enough.
It's actually pretty fun. I already transcribed one piece. It's running a bit slow though. When they said "crowd sourcing", I don't think they meant "slashdot crowd sourcing".
Honestly, you may never be able to convince a budget pusher that testing will save money. What they see is a financial constraint that they may not be able to get around. As a coder, however, you can make YOURSELF more valuable by learning test methodology as a way of life. It has changed the way I think and code. My code is cleaner. I now deliver finished and stable product much faster.
First, let's look at the types of testing you may encounter. The most important, and easiest to introduce, is unit testing. Unit testing effects your approach to building clean, reusable modules. The second is regression testing, which is basically just the practice of keeping all your unit tests and running them ALL every time you add a new module or change an existing one. This keeps your bug fixes or functionality from "regressing". The next, if needed, is stress testing. This is important if you have an app that deals with a lot of data or a lot of user traffic. It helps you determine is there might be an issue with the chosen platform, database engine, even your network "pipes" clogging traffic. The last, and hardest to implement, is UI testing. That route usually requires a set of libraries that compile into your app. There aren't a lot of good ones out there, but the are some new stars rising in the field.
Let's get to the most important one now, unit testing. Unit testing, for a lot of languages can be implemented free and incrementally, which is how I started. If you are running C#, look into NUnit or even Microsoft's testing suite, built into pro versions of VS 2005 or greater. If C++, look at CppUnit. For Java, there is JUnit. If you are using SmallTalk (not very likely) there is the granddaddy of unit testing, SUnit, from which the rest derived. Even Flex and Flash from Adobe has FlexUnit. These are all free (or included in the development tools.) There are other projects out there for other languages but you'll have to research that yourself.
If you have never done unit testing get a book or three on Test Driven Development. It's a pretty large bite to chew, but give it time. This is more about improving your career than fixing a single problem. The basic idea is that, when you start solving a programming problem, break it down into small chunks and write a set of tests that will prove the code for each small chunk. Keep your classes small and focused. This will improve not only testability, but reusability, and inheritability (if those are even words). Don't tie UI code directly to the functionality behind it. This improves testability, but it also makes it easier to change out UI components when a wrong UI decision is corrected. For instance, if you program in a progress bar but the customer wanted a fuel gauge look, the functional code can service the different looks without changing.
Even with unit tested code you will still find bugs. The trick here is to make sure that 1) the classes are small and focused (mentioned earlier), 2) the class (and relevant unit tests) are well documented so that there is no guessing as to why you did what you did, and 3) the unit tests are well organized. When you run into a bug, sometimes just because of bad data in the real world, build a new test that duplicates the condition and fails (throws an error or somesuch), then modify the class(es) to handle the condition. Run that test again to make sure it worked. Then, lastly, run the full suite of tests that you built to see if you brake anything else with your change. This last test (regression testing) is the magic that makes unit testing shine.
I know that this post doesn't directly answer your question, but sometimes, a little understanding goes a long way to helping you ask the right question instead of guessing. Currently, I write about twice as much code as I used to. Half of it is unit tests (maybe more). The quality of my code, however, has greatly improved. I am also able to deliver cleaner code faster. Just like project management, where, if done right, you
For those not too young to remember, Bill Clinton's reelection was guaranteed by the Democrats using the same tactics to get Bob Dole on the Republican ticket. This tactic is distasteful no matter who tries it. What would be intensely hilarious to me would be for Palin to win in 2012 after such meddling. Here's a warning to those Democrats who would stoop to such tactics: She has more support than you think. A true grass roots push coupled with a group of idiots voting outside their party would be enough to tip the pot. How 'bout instead of being dishonest, people, try to find a better candidate than Obama. If he can't win without subterfuge, he doesn't belong on the ticket. Though legal, this is no more morally sound than the Watergate breakins during the Nixon administration.
...there's no reason to get all worked up about it as it has 0 chance of ever passing.
Not been keeping up with the current healthcare insurance bill, have we?
The Challenger disaster was a personal tragedy for many of us. The shuttles represented the resurgence of hope that we were experiencing after 2 decades of societal insanity (60s and 70s). If you're too young to remember or not from the US, the whole nation mourned for quite a while. Having a video that you took of the incident would be akin to keeping a memento of a loved one that you just lost, a personal reminder of what was lost.
I've had very similar experiences with pianos. I'm by no means a master. I don't even consider myself proficient, but the opportunities that I have had to play a really excellent piano made things totally different. From the weight of the keys and their responsiveness to my touch to the acoustic quality and shape of the box surrounding the harp, everything sounded and felt different. I've only been "lost" playing piano twice in my life. Once was on a high end traditional full grand (can't remember the make). The other time was, to my surprise, on an simple Yamaha full keyboard (a high-end electric one with only 2 "voices"). It felt and sounded as good as the grand to me. I was shocked that an electronic device could really produce that sound and have such a velvety feel. It was a dream to play.
If instruments with that level of quality were accessible to everyone I believe that the amount of truly inspiring musical compositions would begin to soar. My piano play began to wane after those experiences simply because everything else left me flat. When you truly enjoy the experience of playing a quality instrument and the instrument itself is not fighting against you in the production of a really beautiful sound your creativity level goes way up.
With the studies out that have definitively proven the link between playing music (including singing) and the increase in abilities in language, math, and science aptitude I begin to wonder if more common access to high quality instruments would help to improve the math, science, and language problems we now have in the education system. I would certainly help reduce the amount of pop-noise that pervades our society today.
PI is a formula that describes a relationship of measurements regarding a circle. The problem being that we know imprecisely the results of that formula without knowing the formula. The search for a repetitive pattern (to help define the formula) in the result is, thus far, proving unproductive. I would wager to guess that, at over 2.5T digits, a found repetition will still not help. Typically, an answer for something this daunting will be far simpler than expected and come from a kid or young adult from the least expected country on the planet. I look forward to that jaw-dropping, Homer Simpson quoting day.
Lost electricity, cell phones ran out of juice. Before that, though, the emergency responders had allocated or saturated the cell capacity.
Land lines stayed up for a month while we had no appreciable cell service or electricity.
Unfortunately, Verizon has started using the home owners electricity to "power" the land lines.
What a cluster....
I found this. It's a product release announcement.
But I believe if the Egyptians were smart enough to use these plants for recreational use , then they should have been smart enough to cultivate them as well...
"Dude, I think I smoked the last plant... ...bummer"
Thanks for the review Adrian! I'm also a .Net 2.0 programmer. Being employed doing 2.0 full time makes it hard to bounce around the net trying to find cohesive 3.5 examples and explanations (that aren't just hacks.) This looks like a good place to do the concentrated study that I need.
As of v4.11 of Novell's NDS (now eDirectory), NDS was a far superior system for managing objects. I was easily managing hundreds of servers and thousands of Windows workstations (using Zen Works) with NDS in the NetWare 4.11/4.12 time frame. This included enterprise software roll out, local NT registry management, software and hardware inventory, and on-demand software delivery. I could easily drop in a replacement PC for a user and it would auto-build the software profile for them. We didn't spend hours trying to fix a user's PC if it was hosed or infected. We swapped their old one for a new one. When they logged in they got their old tools and files (network stored). The old PC was diagnosed and wiped at our leisure.
The programming API for NDS was much simpler that for AD (or LDAP, for that matter). The limitation there was having to use the Watcom C compiler to wrap NetWare NLMs (NetWare Loadable Modules. The old 3.x versions were called VAPs - Value Added Processes).
AD still suffers from old holdover problems (like groups not showing up via one API, but visible in another, or simply showing some members and truncating the list, having to know which server to query, etc...)
Novell's NDS was stronger in the 4.11+ days than AD is now. This includes extensibility, manageability, API, etc... That doesn't mean that MS isn't making progress, just that they should have listened to us back in '97 when we were asking them to license NDS from Novell and drop the death-trap that was AD. We would be 11 years farther on stability and usability if they had.
I have no idea how stable or usable NDS/eDirectory is now. Very few shops depend on it now and I had to drop it from my bag of tricks so that I could focus on what paid the bills.
Here's a basic list of MS non-innovation over time:
Enough ranting... MS is doing better with AD than they were, but it still has a long way to go.
That would be like rebuilding a hurricane flooded city that is below sea level and only protected by weak levies... like that's going to happen! ... oh wait....
Unfortunately, many who focused on programming in college also aren't very skilled in programming...
There are many areas to choose from that don't require skills in programming. You should, however, keep yourself versed in understanding how to read a program. It is a necessary skill no matter what area of expertise you choose.
I wouldn't recommend "support" unless you like being attached to a phone or stuck in a dead-end job diagnosing why a PC won't boot. If have any talent in seeing skills in other people or managing a project, I would recommend PMI certification (Project Management). That allows for a clear path to management.
Another good area is QA/Six Sigma type work. If you are good at math and can wrap your head around the metrics of improvement and testing from a quantitative and qualitative framework, this is an excellent and challenging field. There will be some "programming" involved, but usually things like Excel macros and such that relate to statistics. (On a side not: beware of Excel's statistics related functions. Many of them are terminally ill and have been from the beginning. Verify all your data and test multiple scenarios with a handy TI or HP calculator beside the keyboard.)
In almost all IT-related fields the time from expert to out-of-date is around 6 month if you aren't studying. Security work has a shelf life of 1 to 2 months, though. So unless you don't mind intense study for the entire time you are working, stay abreast of security but avoid it as a career. I do have some friends, however, who love the field and have stayed for years. It's more about your disposition than anything.
On the salary basis, don't get too excited. Since you are just starting out, stay light on your bills and choose a targeted path. If you get stuck on too high a standard of living too early, it is almost impossible to switch jobs, if needed, to better align yourself with your career growth plans. In the first 5 to 7 years, expect to switch around a bit to get into the proper career groove. Then, lay down some time in 1 (maybe 2) semi-long-term spots that are challenging and will grow your skills.
Keep an open mind. I have been a bonifide expert in several technologies that became extinct overnight. You can't really predict with any certainty what will and what won't last. Keep up with multiple areas and technologies at once.
Always keep your eyes open for good high-level positions that you can do with a little stretch. Also keep in touch with education. If you have a BA or BS, go for an MS or two. MBAs may be boring but they open doors for you. PhDs are typically overkill and tend to sap the brains and make the decorated individual quite useless in a real-world IT scenario.
Blog smart, publish often, write books. Even if you stink at writing, get good at it (and get a good editor until you are). The published will always get a job.
About "blog smart"... Don't be stupid. Stay out of politics and your personal life. The Myspace/Facebook generation keeps shooting itself in the foot because all their dirty laundry is aired out in the public. As a very unfortunate example, if you like you music edgy (pick the genre) and blog about it, you could lose out on a job interview to someone with less experience and harder music tastes who doesn't blog about it. Corporate hiring wonks are relying more and more on internet research for candidates.
I've been through 24 years in this industry in everything from programming to system admin to security expert, with a lot of things in between. Stay light, even with a family. This can be a feast or famine industry. Keep your possessions liquidable and classically sparse. When the money rolls in, don't spend it all. Sock it away. Invest some. "matress" some
.NET is nice on Windows, definitely. But on Linux, there are so many more alternatives. It's really that- - Bright yellow crisp mono spaced fonts on a dark blue background. This is great for long work hours without sucking your eyes out of the sockets.
- - Bright white on dark blue. Same reasons. These two combinations, combined with white or yellow on black for highlights, make a good simple combination.
- - For low-light conditions, such as an emap in a car, go with the traditional green on black or amber on black. Amber is prettier but harder to focus on quickly when glancing. Green is definately better. The current mapping systems with bright backgrounds are only good for daytime driving. The brightness of the screen causes temporary night-blindness when glancing back and forth at night.--very dangerous--
- - For modern web and client app interfaces, good contrast without major glare is important.
- - Bright blues are pretty, but are painful to a large percent of the population when exposed over long periods. It has something to do with the monitor focal point regarding blue light. Ask an expert on this.
- - Use semi-bright backgrounds, but not glaring. Muted (not primary) pastels with a crisp font are good. Examples include "dusty" pinks/salmons or dusty greens, yellows, warm blue-grays serve as good majority backgrounds where whites (unless muted) should only be used for highlights.
- - You need to make the fonts crisp and readable. Contrast the colors without causing the "spectral blur" that make it look like a "rainbow" on the edges. It may be a cool effect, but it causes eye strain.
- - Compliment the colors with the expected environment spectrum. An office typically has cool (read cheep) fluorescent lighting and drab office colors. Use a warmer set here. For a home application, use cooler colors due to the typically warmer environment. The contrast is more appealing.
- - Just as you contrast the colors with the environment, compliment the hue and brightness. A bright area should have a bright screen to match where a low light area should have a darker interface to reduce eye strain.
Generally, it takes some practice and a lot of input. Some things are often overlooked. A good example is flashing colors, images, or fonts. Just don't do it. These cause huge eye strain and can even cause epileptic seizures. Layout, also is usually an afterthought. This was just as true back when all computers were dumb terminals attached to a mainframes. Most programmers just stink as designers. Clearly delineated layouts are ***ALMOST*** as important as the color scheme. Remember the old timers' rule of thumb. If a novice computer user who knows nothing of the business background for the application can easily explain to you what the application is for and how to use it, then, and only then, it's a good interface....that the actual culprits (of the most recent "oopses") were an employees of a contractor run by an Obama adviser, John O. Brennan. The previous one was a trainee who was instructed to test the access with a family member's name. I'm neither for nor against Obama, but he crowed the loudest and it was people answering to someone in his camp, not from "the administration". ...interesting...
...man wakes up to find a pile of goo wearing his wife's very clean titanium dioxide pajamas...