New Programming Jargon

by Joey deVilla on May 9, 2010

Every field comes up with its own jargon, and oftentimes subgroups within a field come up with their own specific words or phrases (those of you familiar with Microsoft Canada’s Developer and Platform Evangelism Team know that we have our own term for “broken”, named after one of our teammates who is notorious for killing all sorts of tech gear).

A question recently posted on Stack Overflow asked for people to submit programming terms that they or their team have coined and have come into regular use in their own circles. I took a number of the submissions and compiled them into the alphabetically ordered list below for your education and entertainment.

Have you come up with your own jargon? Tell us in the comments!

Banana Banana Banana

Placeholder text indicating that documentation is in progress or yet to be completed. Mostly used because FxCop complains when a public function lacks documentation.

Example:

/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate(CustomerValidationRequest request, bool ...

Barack Obama

A project management account to which the most aspirational tickets – stuff you’d really like to do but will pobably never get approval for – gets assigned.

Bicrement

Adding 2 to a variable.

Bloombug

A bug that accidentally generates money. [Joey’s note: I have never written one of these.]

Bugfoot

A bug that isn’t reproducible and has been sighted by only one person. See Loch Ness Monster Bug.

Chunky Salsa

A single critical error or bug that renders an entire system unusable, especially in a production environment.

Based on the chunky salsa rule from TVTropes: Any situation that would reduce a character’s head to the consistency of chunky salsa dip is fatal, regardless of other rules.

Configuration Programming / Programmer

Someone that says they are a programmer but only knows how to hack at configuration files of some other pieces of software configuration to make them do what they want.

Counterbug

A defensive move useful for code reviews. If someone reviewing your code presents you with a bug that’s your fault, you counter with a counterbug: a bug caused by the reviewer.

DOCTYPE Decoration

When web designers add a proper DOCTYPE declaration at the beginning of an HTML document, but then don’t bother to write valid markup for the rest of it.

Drug Report

A bug report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought have had one too many.

Duck

A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.

This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “That looks great. Just one thing – get rid of the duck.”

Fear-Driven Development

When project management adds more pressure, such as by firing a member of the team.

Ghetto Code

A particularly inelegant and obviously suboptimal section of code that still meets the requirements. [Joey’s note: I’ve written ghetto code before, but that’s because I’m street, yo!]

Hindenbug

A catastrophic data-destroying bug. Oh, the humanity!

Hocus Focus Problem

Unexpected behavior caused by changes in focus, or incorrect setting of focus. Could also be used to describe an app stealing your focus.

Hot Potato / Hot Potatoes

A fun way to pronounce http:// and https://.

IRQed

Annoyed by interruptions. Pronounced like and has a similar meaning to “irked”.

Jimmy

A generalized name for the clueless/new developer. The submitter at Stack Overflow writes:

We found as we were developing a framework component that required minimal knowledge of how it worked for the other developers. We would always phrase our questions as: “What if Jimmy forgets to update the attribute?”

This led to the term “Jimmy-proof” when referring to well designed framework code.

It’s probably best not to use this term around IronRuby developer Jimmy Schementi.

Loch Ness Monster Bug

A bug that isn’t reproducible and has been sighted by only one person. See Bugfoot.

Megamoth

MEGA MOnolithic meTHod. Usually stretches over two screens in height and often contained inside a God Object (an object that knows or does too much).

.NET Sandwich

When .NET code called native code which calls other .NET code and makes the poorly designed application crash.

n-gleton

A class that only allows a fixed number of instances of itself.

NOPping

Not napping, but simply zoning out. Comes from the assembly language instruction NOP, for No OPeration, which does nothing.

Pokemon Exception Handling

For when you just gotta catch ’em all!

Reality 101 Failure

The program (or more likely feature of a program) does exactly what was asked for, but when it’s deployed it turns out that the problem was misunderstood and the program is basically useless.

Refuctoring

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself. It’s job security!

The Sheath

The isolating interface between your team’s (good) code, and the brain-dead code contributed by some other group. The sheath prevents horrible things (badly named constants, incorrect types, etc.) in their code from infecting your code.

[Joey’s note: I’ve heard the term “shim” used for this sort of construct. I’ve used the term “transmogrifier” for this sort of thing.]

Shrug Report

A bug report with no error message or “how to reproduce” steps and only a vague description of the problem. Usually contains the phrase “doesn’t work.”

Smug Report

A bug report submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Stringly-Typed

A riff on strongly-typed. Used to describe an implementation that needlessly relies on strings when programmer- and refactor-friendly options are available.

Examples:

• Method parameters that take strings when other more appropriate types should be used
• On the occasion that a string is required in a method call (e.g. network service), the string is then passed and used throughout the rest of the call graph without first converting it to a more suitable internal representation (e.g. parse it and create an enum, then you have strong typing throughout the rest of your codebase)
• Message passing without using typed messages etc.

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

Unicorny

An adjective to describe a feature that’s so early in the planning stages that it might as well be imaginary. This one comes from Rails Core Team member Yehuda Katz, who used it in his closing keynote at last year’s Windy City Rails to describe some of Rails’ upcoming features.

Yoda Conditions

The act of using

if (constant == variable)

instead of

if (variable == constant)

It’s like saying “If blue is the sky”.

Article copied from: http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

De asemenea, Cabinetul de Ministri a declarat 4, 5 si 6 ianuarie 2010 zile de odihna. In acest mod angajatii bugetari si institutiile de invatamint si educational vor avea o vacanta intre 1-10 ianuarie. Zilele date vor fi recuperate simbata 16 ianuarie, 13 februarie si, respectiv, 13 martie 2010. Ziua de 25 decembrie va fi recuperata in una din simbetele de pina la finele anului viitor.

In nota informativa se mentioneaza ca hotarirea de Guvern nu afecteaza unitatile si personalul care activeaza in regim continuu la munca sau in regim special.

Rentabilizând moartea

Dacă trăiaţi cu iluzia că cei care au provocat colapsul actual s-au retras discret din prima linie, vă înşelaţi amarnic. Ei nu au părăsit niciodată câmpul de bătălie şi, cred că nu aş exagera dacă aş afirma că, în ultimă instanţă, noţiunea de “câmp de bătălie” în accepţiunea actuală le aparţine întrutotul. Sunt oameni discreţi, aproape obscuri, dar care au o capacitate destructivă fabuloasă. Scopul lor este acela de a face baloane nu de dragul umflatului, ci pentru perceperea comisionului.

1. Inability to reason about code

Reasoning about code means being able to follow the execution path (“running the program in your head”) while knowing what the goal of the code is.

Symptoms

1. The presence of “voodoo code”, or code that has no effect on the goal of the program but is diligently maintained anyway (such as initializing variables that are never used, calling functions that are irrelevant to the goal, producing output that is not used, etc.)
2. Executing idempotent functions multiple times (eg: calling the save() function multiple times “just to be sure”)
3. Fixing bugs by writing code that overwrites the result of the faulty code
4. “Yo-Yo code” that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)
5. “Bulldozer code” that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)

Remedies

To get over this deficiency a programmer can practice by using the IDE’s own debugger as an aide, if it has the ability to step through the code one line at a time. In Visual Studio, for example, this means setting a breakpoint at the beginning of the problem area and stepping through with the ‘F11′ key, inspecting the value of variables–before and after they change–until you understand what the code is doing. If the target environment doesn’t have such a feature, then do your practice-work in one that does.

The goal is to reach a point where you no longer need the debugger to be able to follow the flow of code in your head, and where you are patient enough to think about what the code is doing to the state of the program. The reward is the ability to identify redundant and unnecessary code, as well as how to find bugs in existing code without having to re-implement the whole routine from scratch.

2. Poor understanding of the language’s programming model

Object Oriented Programming is an example of a language model, as is Functional or Declarative programming. They’re each significantly different from procedural or imperative programming, just as procedural programming is significantly different from assembly or GOTO-based programming. Then there are languages which follow a major programming model (such as OOP) but introduce their own improvements such as list comprehensions, generics, duck-typing, etc.

Symptoms

1. Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in their familiar language’s style
2. (OOP) Attempting to call non-static functions or variables in uninstantiated classes, and having difficulty understanding why it won’t compile
3. (OOP) Writing lots of “xxxxxManager” classes that contain all of the methods for manipulating the fields of objects that have little or no methods of their own
4. (Relational) Treating a relational database as an object store and performing all joins and relation enforcement in client code
5. (Functional) Creating multiple versions of the same algorithm to handle different types or operators, rather than passing high-level functions to a generic implementation
6. (Functional) Manually caching the results of a deterministic function on platforms that do it automatically (such as SQL and Haskell)
7. Using cut-n-paste code from someone else’s program to deal with I/O and Monads
8. (Declarative) Setting individual values in imperative code rather than using data-binding

Remedies

If your skills deficiency is a product of ineffective teaching or studying, then an alternative teacher is the compiler itself. There is no more effective way of learning a new programming model than starting a new project and committing yourself to use whatever the new constructs are, intelligently or not. You also need to practice explaining the model’s features in crude terms of whatever you are familiar with, then recursively building on your new vocabulary until you understand the subtleties as well. For example:

Phase 1: “OOP is just records with methods”
Phase 2: “OOP methods are just functions running in a mini-program with its own global variables”
Phase 3: “The global variables are called fields, some of which are private and invisible from outside the mini-program”
Phase 4: “The idea of having private and public elements is to hide implementation details and expose a clean interface, and this is called Encapsulation”
Phase 5: “Encapsulation means my business logic doesn’t need to be polluted with implementation details”

Phase 5 looks the same for all languages, since they are all really trying to get the programmer to the point where he can express the intent of the program without burying it in the specifics of how. Take functional programming as another example:

Phase 1: “Functional programming is just doing everything by chaining deterministic functions together”
Phase 2: “When the functions are deterministic, they don’t need to be executed until the output is called for, and only for as much as needed. This is called Lazy Evaluation and Partial Evaluation”
Phase 3: “In order to support Lazy and Partial Evaluation, the compiler requires that I write functions in terms of how to transform a single parameter, sometimes into another function. This is called Currying”
Phase 4: “When all functions are curried, the compiler can choose the best execution plan”
Phase 5: “By letting the compiler figure out the mundane details, I can write programs by describing what I want, rather than how to give it to me”

3. Deficient research skills / Chronically poor knowledge of the platform’s features

Modern languages and frameworks now come with an awesome breadth and depth of built-in commands and features, with some leading frameworks (Java, .Net, Cocoa) being too large to expect any programmer, even a good one, to learn in anything less than a few years. But a good programmer will search for a built-in function that does what they need before they begin to roll their own, and excellent programmers have the skill to break-down and identify the abstract problems in their task, then search for existing frameworks, patterns, models and languages that can be adapted before they even begin to design the program.

Symptoms

These are only indicative of the problem if they continue to appear in the programmer’s work long after he should have mastered the new platform.

1. Re-inventing or laboring without basic mechanisms that are built-into the language, such as events-and-handlers or regular expressions
2. Re-inventing classes and functions that are built-into the framework (eg: timers, collections, sorting and searching algorithms) *
3. “Email me teh code, plz” messages posted to help forums
4. “Roundabout code” that accomplishes in many instructions what could be done with far fewer (eg: rounding a number by converting a decimal into a formatted string, then converting the string back into a decimal)
5. Persistently using old-fashioned techniques even when new techniques are better in those situations (eg: still writes named delegate functions instead of using lambda expressions)
6. Having a stark “comfort zone”, and going to extreme lengths to solve complex problems with primitives

* – Accidental duplication will also happen, proportionate to the size of the framework, so judge by degree. Someone who hand-rolls a linked list might Know What They Are Doing, but someone who hand-rolls their own StrCpy() probably does not.

Remedies

A programmer can’t acquire this kind of knowledge without slowing down, and it’s likely that he’s been in a rush to get each function working by whatever means necessary. He needs to have the platform’s technical reference handy and be able to look through it with minimal effort, which can mean either having a hard copy of it on the desk right next to the keyboard, or having a second monitor dedicated to a browser. To get into the habit initially, he should refactor his old code with the goal of reducing its instruction count by 10:1 or more.

4. Inability to comprehend pointers

If you don’t understand pointers then there is a very shallow ceiling on the types of programs you can write, as the concept of pointers enables the creation of complex data structures and efficient APIs. Managed languages use references instead of pointers, which are similar but add automatic dereferencing and prohibit pointer arithmetic to eliminate certain classes of bugs. They are still similar enough, however, that a failure to grasp the concept will be reflected in poor data-structure design and bugs that trace back to the difference between pass-by-value and pass-by-reference in method calls.

Symptoms

1. Failure to implement a linked list, or write code that inserts/deletes nodes from linked list or tree without losing data
2. Allocating arbitrarily big arrays for variable-length collections and maintaining a separate collection-size counter, rather than using a dynamic data structure
3. Inability to find or fix bugs caused by mistakenly performing arithmetic on pointers
4. Modifying the dereferenced values from pointers passed as the parameters to a function, and not expecting it to change the values in the scope outside the function
5. Making a copy of a pointer, changing the dereferenced value via the copy, then assuming the original pointer still points to the old value
6. Serializing a pointer to the disk or network when it should have been the dereferenced value
7. Sorting an array of pointers by performing the comparison on the pointers themselves

Remedies

“A friend of mine named Joe was staying somewhere else in the hotel and I didn’t know his room number. But I did know which room his acquaintance, Frank, was staying in. So I went up there and knocked on his door and asked him, ‘Where’s Joe staying?’ Frank didn’t know, but he did know which room Joe’s co-worker, Theodore, was staying in, and gave me that room number instead. So I went to Theodore’s room and asked him where Joe was staying, and Theodore told me that Joe was in Room 414. And that, in fact, is where Joe was.”

Pointers can be described with many different metaphors, and data structures into many analogies. The above is a simple analogy for a linked list, and anybody can invent their own, even if they aren’t programmers. The comprehension failure doesn’t occur when pointers are described, so you can’t describe them any more thoroughly than they already have been. It fails when the programmer then tries to visualize what’s going on in the computer’s memory and gets it conflated with their understanding of regular variables, which are very similar. It may help to translate the code into a simple story to help reason about what’s going on, until the distinction clicks and the programmer can visualize pointers and the data structures they enable as intuitively as scalar values and arrays.

5. Difficulty seeing through recursion

The idea of recursion is easy enough to understand, but programmers often have problems imagining the result of a recursive operation in their minds, or how a complex result can be computed with a simple function. This makes it harder to design a recursive function because you have trouble picturing “where you are” when you come to writing the test for the base condition or the parameters for the recursive call.

Symptoms

1. Hideously complex iterative algorithms for problems that can be solved recursively (eg: traversing a filesystem tree), especially where memory and performance is not a premium
2. Recursive functions that check the same base condition both before and after the recursive call
3. Recursive functions that don’t test for a base condition
4. Recursive subroutines that concatenate/sum to a global variable or a carry-along output variable
5. Apparent confusion about what to pass as the parameter in the recursive call, or recursive calls that pass the parameter unmodified
6. Thinking that the number of iterations is going to be passed as a parameter

Remedies

Get your feet wet and be prepared for some stack overflows. Begin by writing code with only one base-condition check and one recursive call that uses the same, unmodified parameter that was passed. Stop coding even if you have the feeling that it’s not enough, and run it anyway. It throws a stack-overflow exception, so now go back and pass a modified copy of the parameter in the recursive call. More stack overflows? Excessive output? Then do more code-and-run iterations, switching from tweaking your base-condition test to tweaking your recursive call until you start to intuit how the function is transforming its input. Resist the urge to use more than one base-condition test or recursive call unless you really Know What You’re Doing.

Your goal is to have the confidence to jump in, even if you don’t have a complete sense of “where you are” in the imaginary recursive path. Then when you need to write a function for a real project you’d begin by writing a unit test first, and proceeding with the same technique above.

Signs that you are a mediocre programmer

1. Inability to think in sets

Transitioning from imperative programming to functional and declarative programming will immediately require you to think about operating on sets of data as your primitive, not scalar values. The transition is required whenever you use SQL with a relational database (and not as an object store), whenever you design programs that will scale linearly with multiple processors, and whenever you write code that has to execute on a SIMD-capable chip (such as modern graphics cards and video game consoles).

Symptoms

The following count only when they’re seen on a platform with Declarative or Functional programming features that the programmer should be aware of.

1. Performing atomic operations on the elements of a collection within a for or foreach loop
2. Writing Map or Reduce functions that contain their own loop for iterating through the dataset
3. Fetching large datasets from the server and computing sums on the client, instead of using aggregate functions in the query
4. Functions acting on elements in a collection that begin by performing a new database query to fetch a related record
5. Writing business-logic functions with tragically compromising side-effects, such as updating a user interface or performing file I/O
6. Entity classes that open their own database connections or file handles and keep them open for the lifespan of each object

Remedies

Funny enough, visualizing a card dealer cutting a deck of cards and interleaving the two stacks together by flipping through them with his thumbs can jolt the mind into thinking about sets and how you can operate on them in bulk. Other stimulating visualizations are:

• freeway traffic passing through an array of toll booths (parallel processing)
• springs joining to form streams joining to form creeks joining to form rivers (parallel reduce/aggregate functions)
• a newspaper printing press (coroutines, pipelines)
• the zipper tag on a jacket pulling the zipper teeth together (simple joins)
• transfer RNA picking up amino acids and joining messenger RNA within a ribosome to become a protein (multi-stage function-driven joins, see animation)
• the above happening simultaneously in billions of cells in an orange tree to convert soil, water and sunlight into orange juice (Map/Reduce on large distributed clusters)

If you are writing a program that works with collections, think about all the supplemental data and records that your functions need to work on each element and use Map functions to join them together in pairs before you have your Reduce function applied to each pair.

2. Lack of critical thinking

Unless you criticize your own ideas and look for flaws in your own thinking, you will miss problems that can be fixed before you even start coding. If you also fail to criticize your own code once written, you will only learn at the vastly slower pace of trial and error. This problem originates in both lazy thinking and egocentric thinking, so its symptoms seem to come from two different directions.

Symptoms

1. Homebrew “Business Rule Engines”
2. Fat static utility classes, or multi-disciplinary libraries with only one namespace
3. Conglomerate applications, or attaching unrelated features to an existing application to avoid the overhead of starting a new project
4. Architectures that have begun to require epicycles
5. Adding columns to tables for tangential data (eg: putting a “# cars owned” column on your address-book table)
6. Inconsistent naming conventions
7. “Man with a hammer” mentality, or changing the definitions of problems so they can all be solved with one particular technology
8. Programs that dwarf the complexity of the problem they solve
9. Pathologically and redundantly defensive programming (“Enterprisey code”)
10. Re-inventing LISP in XML

Remedies

Start with a book like Critical Thinking by Paul and Elder, work on controlling your ego, and practice resisting the urge to defend yourself as you submit your ideas to friends and colleagues for criticism.

Once you get used to other people examining your ideas, start examining your own ideas yourself and practice imagining the consequences of them. In addition, you also need to develop a sense of proportion (to have a feel for how much design is appropriate for the size of the problem), a habit of fact-checking assumptions (so you don’t overestimate the size of the problem), and a healthy attitude towards failure (even Isaac Newton was wrong about gravity, but we still love him and needed him to try anyway).

Finally, you must have discipline. Being aware of flaws in your plan will not make you more productive unless you can muster the willpower to correct and rebuild what you’re working on.

3. Pinball Programming

When you tilt the board just right, pull back the pin to just the right distance, and hit the flipper buttons in the right sequence, then the program runs flawlessly with the flow of execution bouncing off conditionals and careening unchecked toward the next state transition.

Symptoms

1. One Try-Catch block wrapping the entire body of Main() and resetting the program in the Catch clause (the pinball gutter)
2. Using strings/integers for values that have (or could be given) more appropriate wrapper types in a strongly-typed language
3. Packing complex data into delimited strings and parsing it out in every function that uses it
4. Failing to use assertions or method contracts on functions that take ambiguous input
5. The use of Sleep() to wait for another thread to finish its task
6. Switch statements on non-enumerated values that don’t have an “Otherwise” clause
7. Using Automethods or Reflection to invoke methods that are named in unqualified user input
8. Setting global variables in functions as a way to return multiple values
9. Classes with one method and a couple of fields, where you have to set the fields as the way of passing parameters to the method
10. Multi-row database updates without a transaction
11. Hail-Mary passes (eg: trying to restore the state of a database without a transaction and ROLLBACK)

Remedies

Imagine your program’s input is water. It’s going to fall through every crack and fill every pocket, so you need to think about what the consequences are when it flows somewhere other than where you’ve explicitly built something to catch it.

You will need to make yourself familiar with the mechanisms on your platform that help make programs robust and ductile. There are three basic kinds:

1. those which stop the program before any damage is done when something unexpected happens, then helps you identify what went wrong (type systems, assertions, exceptions, etc.),
2. those which direct program flow to whatever code best handles the contingency (try-catch blocks, multiple dispatch, event driven programming, etc.),
3. those which pause the thread until all your ducks are in a row (WaitUntil commands, mutexes and semaphores, SyncLocks, etc.)

There is also a fourth, Unit Testing, which you use at design time.

Using these ought to become second nature to you, like putting commas and periods in sentences. To get there, go through the above mechanisms (the ones in parenthesis) one at a time and refactor an old program to use them wherever you can cram them, even if it doesn’t turn out to be appropriate (especially when they don’t seem appropriate, so you also begin to understand why).

4. Unfamiliar with the principles of security

If the following symptoms weren’t so dangerous they’d be little more than an issue of fit-n-finish for most programs, meaning they don’t make you a bad programmer, just a programmer who shouldn’t work on network programs or secure systems until he’s done a bit of homework.

Symptoms

1. Storing exploitable information (names, card numbers, passwords, etc.) in plaintext
2. Storing exploitable information with ineffective encryption (symmetric ciphers with the password compiled into the program; trivial passwords; any “decoder-ring”, homebrew, proprietary or unproven ciphers)
3. Programs or installations that don’t limit their privileges before accepting network connections or interpreting input from untrusted sources
4. Not performing bounds checking or input validation, especially when using unmanaged languages
5. Constructing SQL queries by string concatenation with unvalidated or unescaped input
6. Invoking programs named by user input
7. Code that tries to prevent an exploit from working by searching for the exploit’s signature
8. Credit card numbers or passwords that are stored in an unsalted hash

Remedies

The following only covers basic principles, but they’ll avoid most of the egregious errors that can compromise an entire system. For any system that handles or stores information of value to you or its users, or that controls a valuable resource, always have a security professional review the design and implementation.

Begin by auditing your programs for code that stores input in an array or other kind of allocated memory and make sure it checks that the size of the input doesn’t exceed the memory allocated for storing it. No other class of bug has caused more exploitable security holes than the buffer overflow, and to such an extent that you should seriously consider a memory-managed language when writing network programs, or anywhere security is a priority.

Next, audit for database queries that concatenate unmodified input into the body of a SQL query and switch to using parameterized queries if the platform supports it, or filter/escape all input if not. This is to prevent SQL-injection attacks.

After you’ve de-fanged the two most infamous classes of security bug you should continue thinking about all program input as completely untrustworthy and potentially malicious. It’s important to define your program’s acceptable input in the form of working validation code, and your program should reject input unless it passes validation so that you can fix exploitable holes by fixing the validation and making it more specific, rather than scanning for the signatures of known exploits.

Going further, you should always think about what operations your program needs to perform and the privileges it’ll need from the host to do them before you even begin designing it, because this is the best opportunity to figure out how to write the program to use the fewest privileges possible. The principle behind this is to limit the damage that could be caused to the rest of the system if an exploitable bug was found in your code. In other words: after you’ve learned not to trust your input you should also learn not to trust your own programs.

The last you should learn are the basics of encryption, beginning with Kerckhoff’s principle. It can be expressed as “the security should be in the key”, and there are a couple of interesting points to derive from it.

The first is that you should never trust a cipher or other crypto primitive unless it is published openly and has been analyzed and tested extensively by the greater security community. There is no security in obscurity, proprietary, or newness, as far as cryptography goes. Even implementations of trusted crypto primitives can have flaws, so avoid implementations you aren’t sure have been thoroughly reviewed (including your own). All new cryptosystems enter a pipeline of scrutiny that can be a decade long or more, and you want to limit yourself to the ones that come out of the end with all their known faults fixed.

The second is that if the key is weak, or stored improperly, then it’s as bad as having no encryption at all. If your program needs to encrypt data, but not decrypt it, or decrypt only on rare occasions, then consider giving it only the public key of an asymmetric cipher key pair and making the decryption stage run separately with the private key secured with a good passphrase that the user must enter each time.

The more is at stake, then the more homework you need to do and the more thought you must put into the design phase of the program, all because security is the one feature that dozens, sometimes millions of uninvited people will try to break after your program has been deployed.

The vast majority of security failures traceable to code have been due to silly mistakes, most of which can be avoided by screening input, using resources conservatively, using common sense, and writing code no faster than you can think and reason about it.

Signs that you shouldn’t be a programmer

The following may not have any remedies if you still suffer from them after taking a programming course in school, so you will stand a better chance of advancing your career by choosing another profession.

1. Inability to determine the order of program execution

Symptoms

a = 5
b = 10
a = b

print a

1. You look at the code above and aren’t sure what number gets printed out at the end

Alternative careers

1. Electrician
2. Plumber
3. Architect
4. Civil engineer

2. Insufficient ability to think abstractly

Symptoms

1. Difficulty comprehending the difference between objects and classes
2. Difficulty implementing design patterns for your program
3. Difficulty writing functions with low cohesion
4. Incompetence with Regular Expressions
5. Lisp is opaque to you
6. Cannot fathom the Church-Turing Thesis

Alternative careers

1. Contract negotiator
2. Method actor

3. Collyer Brothers syndrome

Symptoms

1. Unwilling to throw away anything, including garbage
2. Unwilling to delete anything, be it code or comments
3. The urge to build booby-traps for defense against trespassers
4. Unwilling to communicate with other people
5. Poor organization skills

Alternative careers

1. Antique dealer
2. Bag lady

4. Dysfunctional sense of causality

Symptoms

1. You seriously consider malice to be a reason why the compiler rejects your program
2. When called on to fix a bug in a deployed program, you try prayer
3. You take hidden variables for granted and don’t think twice about blaming them for a program’s misbehavior
4. You think the presence of code in a program will affect its runtime behavior, even if it is never invoked *
5. Your debugging repertoire includes rituals like shining your lucky golf ball, twisting your wedding ring, and tapping the nodding-dog toy on your monitor. And when the debugging doesn’t work, you think it might be because you missed one or didn’t do them in the right order

Alternative careers

1. Playing the slot machines in Vegas

5. Indifference to outcomes

Programming could still be a hobby for you, but it would be in society’s best interests to defend itself against your entry into the world of professional software development.

Symptoms

1. You aren’t interested in fixing a bug that can be worked around by rebooting the computer
2. Your installation program silently deploys unsolicited third party programs that are unrelated to the function of yours *
3. You don’t use any ergonomic model when designing user interfaces, nor do you have any interest in usability studies
4. Your program exhibits pretension and grandeur beyond its utility, eg: displaying splash screens over active programs while loading in the background, or placing multiple launch icons in premium desktop locations *
5. Your program produces output to be read by another (eg: a browser), or implements a network protocol, and relies on the other party’s software to be significantly tolerant to spec violations
6. You write busy-wait loops even when the platform offers event-driven programming
7. You don’t use managed languages and can’t be bothered to do bounds checking or input validation
8. Your user interfaces do not make the difficulty of accidentally invoking a function proportionate to its destructiveness (eg: the “Delete Database” button is next to “Save”, just as big, has no confirmation step and no undo)
9. You don’t use whitespace, indentation or comments

* – These are actually imposed by management more often than by the programmer, who only implements them. We’d still group them together for the sake of this self-test, though, and at the most suggest that one seek employment at a better firm, while the other goes back to business school to learn less destructive ways of making a profit.

Alternative careers

1. Debt collection
2. Telemarketing

The Mexican replied, “only a little while.”

The American then asked why didn’t he stay out longer and catch more fish?

The Mexican said he had enough to support his family’s immediate needs.

The American then asked, “but what do you do with the rest of your time?”

The Mexican fisherman said, “I sleep late, fish a little, play with my children, take siestas with my wife, Maria, stroll into the village each evening where I sip wine, and play guitar with my amigos.  I have a full and busy life.”

The American scoffed, “I am a Harvard MBA and could help you.  You should spend more time fishing and with the proceeds, buy a bigger boat.  With the proceeds from the bigger boat, you could buy several boats, eventually you would have a fleet of fishing boats.  Instead of selling your catch to a middleman you would sell directly to the processor, eventually opening your own cannery.  You would control the product, processing, and distribution.  You would need to leave this small coastal fishing village and move to Mexico City, then LA and eventually New York City, where you will run your expanding enterprise.”

The Mexican fisherman asked, “But, how long will this all take?”

To which the American replied, “15 – 20 years.”

“But what then?” Asked the Mexican.

The American laughed and said, “That’s the best part.  When the time is right you would announce an IPO and sell your company stock to the public and become very rich, you would make millions!”

“Millions – then what?”

The American said, “Then you would retire.  Move to a small coastal fishing village where you would sleep late, fish a little, play with your kids, take siestas with your wife, stroll to the village in the evenings where you could sip wine and play your guitar with your amigos.”

Source: http://www.protolink.com/MexicanFisherman.html

The Geemail application is available in .air format. geemail The installation is very simple, first install Adobe AIR and then extract the geemail.air file from the downloaded Geemail file. Double click on the Geemail.air file and the installation will start. In my case the installation did not finish and I received an error that installation did not finish as there might be problem with the installer package. I closed the installer and started the installation again and it got installaed. Features: Offline access lets you compose and send e-mail even if the PC is not connected to Internet. Once it finds an active Internet connection it will automatically send the mail. Zero Configuration does not require you to configure any POP3 or IMAP parameters. Just install it and login using your user name and password and you are done. Cross Platform available for the 3 most popular Operating systems viz Windows, MAC and Linux. Familiar user Interface the Geemail user interface is same as the interface you see once you log in to the web based email. So you do not need to learn a different interface. This Beta version lacks several feastures in Gmail, however I strongly believe that by the time the final version is releassed it will be loaded with many features. This is suitable for those using a dial up connecton or do not have the prviledge of always on Internet connection.

1. Your life or your money.

In the original Legend of Zelda for the Nintendo Entertainment System (1987), there was a mean old man who would lock you in a room in a deadly underground labyrinth and demand that you “leave your life or money.” You had to give up either 50-100 rupees or a heart container in order to proceed.

That’s not so different from employment, is it? If you want to quit your job so you can have a life, you have to give up the money. If you want the money, you have to hand over control of your life. I don’t think either choice is acceptable.

Image from The Legend of Zelda (1987).

2. Who do you want to decide your life purpose?

Do you believe that your life is supposed to have a purpose? That you’re here for a reason and that the world will be better off with you doing what you’re supposed to do? If so, who do you want to decide your life purpose—you or your boss? Beyond the industry you choose, you don’t really have much influence on your life purpose. Every task your boss gives you advances their vision of your life purpose, not yours.

3. You’re a pet at best, and a slave at worst.

When your boss says “jump,” you say “how high?” Either that, or you later say “I’m here to file an unemployment claim.” They’re the one in control, make no mistake of that. So it’s really up to chance whether your boss wants to treat you as a slave, or has enough mercy to promote you to the rank of pet.

As a pet, you jump through hoops in return for handouts that let you tread water until the next payday. You spend your days doing soulless work for a master who might be nice to you, but who assigns you tasks that are appropriate for the dog you are. You make plans and then have to tell people you’re canceling because you have to work late. You go through annual performance reviews to see if you jumped through all the red hoops, the white hoops, and the bonus blue hoops you didn’t even know about. If so, you might get a treat. If not, your master might decide to put you down.

As a slave, you have all the disadvantages of being a pet, plus you have to get used to saying “thank you sir, may I have another?” Your work is cruel and unusual punishment. You get to work way too early and stay way too late because the time you clock is all that matters. You get whatever vacation time you get, and disappoint your family when you don’t have enough time to do what you planned. When you get sick, you go to work while coughing up blood because you have no vacation time to spare. If you luck into a role that you find remotely tolerable, your master might end up selling you to a new master who has different plans for you. C’est la vie.

4. It’s way too communistic.

In a capitalist society, if two people are doing the same job, but one person’s performance is double that of the other’s, who gets paid more? The high performer, of course! They should get twice as much money for twice the output. An employee’s purpose is to help the company complete its work, and they should be paid in proportion to how well they do that.

Oh, if only it were so! In the real world, people are all widgets, and one is the same as another. Performance is often not a factor at all in your compensation. There are people like sales agents and athletes who do get paid based on performance, but most people get a fixed salary based on the position they hold and the number of candles on the cake. Do everything or do nothing, it doesn’t matter. A system like this rewards the weak and punishes the strong.

5. The rat race.

They call it the rat race for a reason. The next time you see a rat running around in its wheel, take a good hard look at it. Notice that it doesn’t look happy. Notice that it works as hard as it can but doesn’t actually go anywhere. Notice that it keeps running without really knowing why. Notice that it doesn’t have any plan for ever being able to stop. Now I ask you, do you think you’re better than a rat?

6. Your boss is an evil bovine master.

I’m going to borrow this one from Steve Pavlina’s 10 Reasons You Should Never Get A Job. It’s #6 on his list; just visit the link to look it up.

7. 9-5 was once a bad idea, and is now a fond memory.

I suppose the 9-5 workday once made sense…if you were an assembly line worker. During the Industrial Revolution, time and output were perfectly interchangeable. A worker would put in an hour of labor and produce a certain number of widgets. It was the same number of widgets in the first hour as it was in the last. Having everyone work the same schedule made sense because it was more efficient to run an assembly line that way, and besides, the workers really didn’t have anywhere else to be.

But what about nowadays? Does 9-5 make sense now? Most people work in jobs that don’t require their physical presence all the time, and perform work that can’t be done at peak capacity for eight hours straight, especially when they have errands that can only be run during the day. Doesn’t it make sense for people to be able to set their own schedules so they can work at their times of peak performance?

Another thing is that who works 9-5 anymore? Outside of the government, schedules like 9-6, 8-6, and 7-7 are much more common.

8. Sitting in traffic isn’t as much fun as you think.

How long is your commute? Maybe you’re currently very lucky and only have to spend twenty minutes each way burning gas, wearing down your brakes, and looking at all the smiling faces you see along the way. But that’s not too likely. In fact, Americans spend more time commuting than taking vacations. Are you sure you can’t think of anything you’d rather be doing than sitting in traffic?

9. The middle class is no class.

Most employees have no control over their income. If you want to make $100,000 a year but your boss decides the position will pay $70,000 a year, who do you think wins?

If a 3% raise is in your company’s budget, that’s what you get. It doesn’t matter if inflation is 4% so your “raise” is actually a pay cut. You get what you get.

The average savings rate in the U.S. has gone from low to very low to zero to negative. People are not only in debt, but their debt is increasing each month because they can’t make the payments. They’re in danger of losing their houses, and cringe every time the price of oil shoots up. They’re forced to spend less time with their families so they can work overtime in an attempt to keep up. It’s a vicious cycle, and they can only hope to break it before they’re working at Wal-Mart in their 70s.

10. “I’m lucky just to have a job.”

The harsh reality of employment is that even though you’re not the captain, you may still have to go down with the ship. During the dot-com bust, the rallying cry of those of us in software development was “I’m lucky just to have a job.” Does that sound like a fun way to go through life, considering yourself to be lucky because even your job that you hate is still better than none at all? I’d rather be in a situation where I consider myself lucky to have enough time, money, and purpose to enjoy life. What about you?

First, the good news: In general, IT skills remain in demand despite the recession. According to Foote’s recent research, culled in part from surveying a pool of 84,000 IT professionals in 1,960 companies in the U.S. and Canada, a majority of IT workers surveyed continue to get at least 7 percent of their pay for specific skills, such as networking, security, database management, or project management.

The bad news? Some specialized skills, including Web development, have suffered a reduction in demand.

David Foote, CEO of the eponymous firm, says demand has grown for IT skills related to project management, architecture, and security. According to data from a set of 22,550 respondents to Foote’s survey, IT security certifications grew nearly 6 percent over the last two years as a percentage of overall median pay.

But the same sample of respondents reported that skills related to Web development certifications dropped 36.8 percent as a percentage of median pay in the same timeframe.

Foote’s research in the area of non-certified IT skills reveals a similar trend: Over the last two years, respondents have reported that management, methodology, and process skills have grown as a percentage of IT staffers’ premium pay by nearly 21 percent. In contrast, Web and e-commerce development has grown just 3.5 percent as a non-certified skill.

What gives? Isn’t the Web the way forward for many IT pros?

David Foote says many firms, especially in healthcare, retail, finance, and education, hired an abundance of experts in specific kinds of online applications in recent years. Many of these were pilot projects, and when the going’s gotten tough, they have been cut mercilessly.

At the same time, Foote points out that demand has risen for IT skills involved in designing and overseeing an organizational move to automated processes in the data center. Ironically, being able to help design and implement technology that reduces headcount is more popular than swelling the IT ranks with specialized Web-related expertise.

Further, these kinds of skills will come in handy as industries consolidate: “With the anticipated escalation in recession-driven mergers and acquisitions creating an enormous amount of integration-related activity, IT architecture and project management expertise are [sic] in more demand than ever,” Foote writes in his report’s executive summary.

Another expert confirms the trend. “Enterprises today are more concerned with solving business problems than with employing the ‘latest technology,’ ” writes Tom Nolle, CEO of the CIMI Corp. consultancy, in an email. “If you go to the online forums for IT and networking, you find all kinds of questions that sound like, ‘Why can’t my management accept that my ideas need to be implemented even if I can’t prove any business value whatsoever?’ The executives look at this sort of thing and laugh. Project managers are typically very connected to the business justification and becoming ever more so, and technical types are fleeing justification more every day.”

Bottom line? IT is still hiring, and online applications are still important, but demand has shifted from specialized skills, including Web development, to architectural expertise.
Source:InternetEvolution Written by Mary Jander

In Mozambic exista un fruct de culoare galbena foarte aromatizat si placut la gust cunoscut sub numele de Amarula. Oamenii il folosesc la prepararea bauturilor alcoolice. Fructele pot fi mancate numai cand sunt foarte bine coapte. Compozitia lor contine cca 17% alcool, dar cand deja sunt prea coapte si cad singure din copac fermenteaza, iar continutul de alcool este si mai mare. Toate animalele din zona apropiata copacilor plini de amarule sunt ametite de la acoolul continut de fructe.
Sursa Text: http://www.swampblog.info/

Microwaved Food

REPRINTED FROM BEYOND HEALTH® News

Microwaved Food

by Raymond Francis

More than 90% of homes in the US have a microwave oven. Builders routinely install these ovens in new homes and hardly a restaurant is without one. They are fast, convenient, economical, and ideally suited to the fast pace of modern lifestyles. There is only one problem with microwave ovens—they are extremely hazardous to your health. It is hard to conceive of any reasonable person who would eat microwaved foods if they understood the hazards. Obviously, very few people truly comprehend these hazards. And no one is rushing to educate them! Let’s have a look at some of the problems with this technology:

Microwaves, very short waves of electromagnetic energy, are just part of Mother Nature’s energy spectrum. This spectrum includes visible, infrared, and ultraviolet light along with radio waves, x-rays, and so forth. Microwaves are generated by the sun along with visible light and the other invisible parts of the spectrum. However, there is a big difference between what the sun generates and what is generated in a microwave oven. This difference is the result of the alternating current used to generate the oven microwaves.

Here is how microwaves cook food: All electromagnetic waves change from positive to negative with each cycle of the wave. Alternating current simply makes these cycles happen faster. Water molecules have a positive and a negative end. Because of this, when exposed to microwave energy, which is changing from positive to negative, the water molecules rotate. This is similar to making a pin rotate on a surface by using a magnet. Microwaves, generated by the alternating current in an oven, cause the water molecules in the food to rotate billions of times per second. This results in an enormous amount of friction among these molecules, thus causing the food to get hot.

It has been generally assumed that microwaved foods are safe to eat. In fact, the only concern of our regulators has been about the leakage of microwaves from the oven. Surprisingly, regulators have never questioned whether the microwaved foods themselves are safe.

In 1991, an early clue that microwaved food is not safe came to public attention in the form of a lawsuit. The family of one Norma Levitt sued for wrongful death. It seems Norma went to the hospital for hip replacement surgery. The operation was a success, but the patient died. Norma died after being given a blood transfusion where the blood had been warmed in a microwave oven. This was our first big clue to the fact that heating things in a microwave does something fundamental and harmful to the chemistry of what is being heated. If microwaving, only long enough to warm the blood to body temperature, could make the blood toxic enough to kill, then what happens when we microwave food for a longer period at higher temperatures?

A lot more goes on in a microwave oven than just making things hot. The enormous amount of energy going into the food molecules is sufficient to break protein molecules apart and cause them to react in ways that they would not otherwise do. As a result, a lot of strange new molecules are created and this is the problem. The molecular structure of the food is changed, thus producing molecules that the body does not recognize. These strange new molecules are unnatural to the body and can be carcinogenic and toxic. This explains why significant biochemical changes have been measured in those eating microwaved food.

Swiss Experiments

Experiments performed in Switzerland by Dr. Hans Hertel along with Dr. Bernard Blanc of the Swiss Federal Institute of Technology found that microwaving damaged the nutritional quality of food. They also measured pathological changes in the blood of volunteers who ate the microwaved food. Hertel and Blanc’s findings are both profound and shocking. These researchers found a decrease in the hemoglobin content of the blood. This means that the blood will carry less oxygen and that the body’s tissues may not be getting all the oxygen they need. White cell count and cholesterol both increased. An increase in white cells indicates stress on the body. White cells go up in response to acute infections, toxins, and cell damage. Lymphocytes decreased. Lymphocytes are a particular kind of white cell that is important to antibody production. None of these happenings are good for you. An immune system in crisis and oxygen starved tissues may not be what you had in mind when you put the food in the oven. And as if that wasn’t bad enough, they also found that serum from the blood of the volunteers who ate the microwaved food caused an increase in the luminescence of light-emitting bacteria. It appears that energy from the microwaving was stored in the molecular bonds of the food. This caused changes in the energy pattern of the blood, thus stimulating these bacteria to emit light when exposed to the blood serum. This finding raises the question of whether it is even safe to drink microwaved water. There may be residual energy stored in the atomic bonds of the water atoms. What all this is telling us is that microwaved food contains both molecules and energies that are not normal to the food. Introducing abnormal molecules and energies into the body is not conducive to good health. Let’s see what other studies tell us this can mean…

Studies in the Soviet Union

A significant amount of research into the hazards of microwaves was performed in the former Soviet Union. These studies were conducted at the Institute of Radio Technology at Kinsk. They led to the discovery of serious health problems associated with exposure to microwaves and the consumption of microwaved food. As a consequence, the Soviet Union outlawed microwave ovens in 1976 and set very strict limits on microwave exposure. The Soviets issued an international warning on both the environmental and biological health hazards of microwave ovens and other microwave devices. Some of the Soviet findings were published in this country by the Atlantis Rising Educational Center in Portland, Oregon.

The Soviets found that microwaving food caused the production of well-known carcinogens, regardless of the type of food. Meats, dairy, grains, fruits, and vegetables all formed known cancer-causing chemicals. In addition, these researchers observed disorders in the digestive systems, malfunctions in the lymphatic systems, and an increase of cancerous cells in the blood of those who ate microwaved foods. They found a statistically high correlation between those who ate microwaved foods and cancer of the stomach and intestines and a gradual breakdown of the function of the digestive system.

The Soviets also found decreases in the nutritional quality of all the foods researched. The nutritional quality of microwaved food decreased by 60 to 90%. These included decreased bioavailability of minerals, B vitamins, vitamins C and E, and lipotropic factors. Even the nutritional value of proteins was decreased.

Hormonal abnormalities were also observed, especially in the production and balancing of male and female hormones. A destabilization in the electrical potential of cell membranes was observed. Maintaining a normal electrical potential in cell membranes is critical to cellular health and to cell-to-cell communication. Continual eating of microwaved food caused permanent brain damage resulting in memory loss, inability to concentrate, emotional upsets, and a decrease in intelligence.

Dr. Lita Lee

Dr. Lita Lee, author of Health Effects of Microwave Radiation—Microwave Ovens, has been a guest on my radio show. She wrote in her book that every microwave oven leaks radiation, and that foods cooked in them develop toxic and carcinogenic by-products. Dr. Lee observed disease patterns among consumers of microwaved foods that included lymphatic disorders, which often lead to the increased probability of certain types of cancers, including increased rates of stomach and intestinal cancers, and higher rates of digestive disorders.

Conclusion

There are three things to remember here. One is that microwaving food creates new chemical compounds that are toxic and even carcinogenic. The second is that the nutritional value of the food is significantly reduced. The third is the silent, but measurable effects in your body when you eat microwaved food. Such foods appear to promote cancer, hormonal imbalances, lymphatic disorders, digestive disorders, blood and immune abnormalities, emotional problems, permanent brain damage and even heart disease.

Given all the above, it is difficult to conceive of anyone who would want to continue to eat microwaved food. To be sure of avoiding all microwaved foods, one has to ask in restaurants if any of the food you are ordering will be heated in a microwave. If so, don’t order it. Based on the data I have seen to date, I recommend that you unplug your microwave and never use it again.

Raymond Francis is an M.I.T.-trained scientist, a registered nutrition consultant, author of Never Be Sick Again and Never Be Fat Again, host of the Beyond Health Show, Chairman of the The Project to End Disease and an internationally recognized leader in the field of optimal health maintenance.

Reprinted with permission from:
Beyond Health® News
Subscriptions: Call 800-250-3063

website: http://www.beyondhealth.com
email: mail@beyondhealth.com

Copyright 2000, Raymond Francis