0

Amazing book for developers or programmers “The Developer’s Code”

The Developer’s code

The Developer’s code

Hullo friends and fellow developers; i got this interesting email from a friend of mine recommending an online book for developers.

I have found this very interesting and i would like to to read it.

To read the book click HERE, or check bellow for contents.

Table of Contents

  • Introduction
  • Metaphor
    • #1: Be wary of metaphors in web development
    • #2: Plan enough, then build
    • #3: Understand launch and Version 2.0
    • #4: The “Ivory Tower” Architect is a myth
    • #5: Specialization isn’t mandatory
    • #6: Metaphors can hurt both ways
  • Motivation
    • #7: Motivation starts with the opportunity to build something well
    • #8: Begin where you love to begin
    • #9: Be imperfect
    • #10: Stop programming
    • #11: Test your work first thing in the morning
    • #12: Don’t work in your bedroom
    • #13: Don’t let bad first impressions of your work unravel you
    • #14: Never underestimate the emotional value of finishing
  • Productivity
    • #15: Just say “no” to the pet project
    • #16: Set a deadline, even if it’s arbitrary
    • #17: Constrain your parameters
    • #18: Cut the detail out of the timeline
    • #19: Make your product better in two ways everyday
    • #20: Invest in good hardware
    • #21: Establish “off-time” and let your co-workers do so too
    • #22: Keep a personal to-do list
    • #23: Write code as a last resort
  • Automation
    • #24: Separate human work from robot work
    • #25: Take advantage of a machine’s strengths
    • #26: Think automation
    • #27: Know the ingredients of a good code generator
    • #28: Avoid touching generated code with bare hands
    • #29: Writing a code generator makes you a better programmer
    • #30: Speak, think, and write code in a ubiquitous language
    • #31: Generated code makes errors obvious and small modifications powerful
    • #32: Address the naysayers
    • #33: Automating software is not like fast-food
  • Complexity
    • #34: Snuffing out bad complexity
    • #35: The simplicity paradox
    • #36: Complexity as a game of pick-up sticks
    • #37: Complexity underneath the surface != Complexity at the surface
    • #38: Hard to code might mean hard to use
    • #39: Design patterns and the danger of anticipation
    • #40: Programming Cadence
  • Teaching
    • #41: An expert coder doth not an expert teacher make
    • #42: Prevent the “Curse of Knowledge” from creeping into your teaching
    • #43: Teach with obvious examples
    • #44: In the beginning, go for blanket statements over the truth
    • #45: Encourage autonomous thought
  • Clients
    • #46: Difficult clients are not uniquely our problem
    • #47: Teach clients what programming actually is
    • #48: Define the goals of your application, seriously
    • #49: Make your work interesting
    • #50: Be forgiving and personable
  • Pride
    • We have a marketing problem
    • Lessons from the cooking industry
0

Secure or Defensive Programming Practices

Of late some guys have been attacking me and making my days miserable. And that is when I reached out for help from my buddy George! He is a great guy, but this time he slapped me in the face, hey don’t get me wrong he is not violent, he just told me the hard truth! Of which I would like to share with all you guys that develop web-systems and websites.

“You can avoid most of these issues by adopting a good web framework, and developing expertise in it, so they can extend it to handle pretty much any task but often, as developers, our ego gets in the way; we want to do our own thing from scratch but the thing is, we’re ALWAYS going to use someone else’s code whether it’s an external library, a hashing algorithm, etc”

At that moment it hit me at how many times I have run to Google, and trust me, I have found the internet resourceful! Which puzzles me, why do we refuse to use frameworks or even the free CMS that are ready in place?

Anyway let me stop accusing you for no good reason below id the check list for Secure Coding Practices; let me know how clean you are? If you’re guilt like I was, please repent, the internet is a jungle with all types of humans, you need to ensure you’re safe.

Secure Coding Practices check list;

1.       Input Validation

2.       Output Encoding

3.       Authentication and Password Management

4.       Session Management

5.       Access Control

6.       Cryptographic Practices

7.       Error Handling and Logging

8.       Data Protection

9.       Communication Security

10.   System Configuration

11.   Database Security

12.   File Management

13.   Memory Management

14.   General Coding Practices

15.   External References

REF: OWASP Secure Coding Practices

1.      Input Validation:

  • Encode data to a common character set before validating (Canonicalize) If any potentially hazardous characters must be allowed as input, be sure that you implement additional controls like output encoding, secure task specific APIs and accounting for the utilization of that data throughout the application . Examples of common hazardous characters include: < > " ' % ( ) & + \ \' \"
  • Validate all data inputs, both on trusted and untrusted sources before processing, including all parameters, URLs and HTTP header content (e.g. Cookie names and values). Be sure to include automated post backs from JavaScript, Flash or other embedded code. All validation failures should result in input rejection. Below are some checks you need to perform.

o   Validate all input against a “white” list of allowed characters, whenever possible

o   Validate for expected data types

o    Validate data range

o    Validate data length

o   Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect)

o   Check for null bytes (%00)

o   Check for new line characters (%0d, %0a, \r, \n)

o   Check for “dot-dot-slash” (../ or ..\) path alterations characters. In cases where UTF-8 extended character set encoding is supported, address alternate representation like: %c0%ae%c0%ae/

  • Specify proper character sets, such as UTF-8, for all sources of input and determine if the system supports UTF-8 extended character sets and if so, validate after UTF-8 decoding is completed
  • Verify that header values in both requests and responses contain only ASCII characters

 

2.      Output Encoding:

  • Conduct all encoding on a trusted system (e.g., The server)
  • Utilize a standard, tested routine for each type of outbound encoding
  • Contextually output encode all data returned to the client that originated outside the application’s trust boundary. HTML entity encoding is one example, but does not work in all cases
  • Encode all characters unless they are known to be safe for the intended interpreter
  • Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP
  • Sanitize all output of un-trusted data to operating system commands
  • November 2010 Version 2.0 6

 

3.      Authentication and Password Management:

  • Require authentication for all pages and resources, except those specifically intended to be public  and all authentication controls must be enforced on a trusted system (e.g., The server)
  • Establish and utilize standard, tested, authentication services whenever possible
  • Use a centralized implementation for all authentication controls, including libraries that call external authentication services
  • Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control
  • All authentication controls should fail securely
  • All administrative and account management functions must be at least as secure as the primary authentication mechanism
  • If your application manages a credential store, it should ensure that only cryptographically strong one-way salted hashes of passwords are stored and that the table/file that stores the passwords and keys is write-able only by the application. (Do not use the MD5 algorithm if it can be avoided)
  • Password hashing must be implemented on a trusted system (e.g., The server).
  • Validate the authentication data only on completion of all data input, especially for sequential authentication implementations
  • Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of “Invalid username” or “Invalid password”, just use “Invalid username and/or password” for both. Error responses must be truly identical in both display and source code
  • Utilize authentication for connections to external systems that involve sensitive information or functions
  • Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system (e.g., The server). The source code is NOT a secure location
  • Use only HTTP POST requests to transmit authentication credentials
  • Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception
  • Enforce password complexity requirements established by policy or regulation. Authentication credentials should be sufficient to withstand attacks that are typical of the threats in the deployed environment. (e.g., requiring the use of alphabetic as well as numeric and/or special characters)
  • Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases
  • Password entry should be obscured on the user’s screen. (e.g., on web forms use the input type “password”)
  • Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, but not so long as to allow for a denial-of-service attack to be performed
  • Password reset and changing operations require the same level of controls as account creation and authentication.
  • Password reset questions should support sufficiently random answers. (e.g., “favorite book” is a bad question because “The Bible” is a very common answer)
  • If using email based resets, only send email to a pre-registered address with a temporary link/password
  • Temporary passwords and links should have a short expiration time
  • Enforce the changing of temporary passwords on the next use
  • November 2010 Version 2.0 7
  • Notify users when a password reset occurs
  • Prevent password re-use
  • Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use
  • Enforce password changes based on requirements established in policy or regulation. Critical systems may require more frequent changes. The time between resets must be administratively controlled
  • Disable “remember me” functionality for password fields
  • The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login
  • Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed
  • Change all vendor-supplied default passwords and user IDs or disable the associated accounts
  • Re-authenticate users prior to performing critical operations
  • Use Multi-Factor Authentication for highly sensitive or high value transactional accounts
  • If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code

 

4.      Session Management:

  • Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid
  • Session identifier creation must always be done on a trusted system (e.g., The server)
  • Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers
  • Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site
  • Logout functionality should fully terminate the associated session or connection
  • Logout functionality should be available from all pages protected by authorization
  • Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours
  • Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts
  • If a session was established before login, close that session and establish a new session after a successful login
  • Generate a new session identifier on any re-authentication
  • Do not allow concurrent logins with the same user ID
  • Do not expose session identifiers in URLs, error messages or logs. Session identifiers should only be located in the HTTP cookie header. For example, do not pass session identifiers as GET parameters
  • Protect server side session data from unauthorized access, by other users of the server, by implementing appropriate access controls on the server
  • Generate a new session identifier and deactivate the old one periodically. (This can mitigate certain session hijacking scenarios where the original identifier was compromised)
  • Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication. Within an application, it is recommended to consistently utilize HTTPS rather than switching between HTTP to HTTPS.
  • November 2010 Version 2.0 8
  • Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks
  • Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters
  • Set the “secure” attribute for cookies transmitted over an TLS connection
  • Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie’s value

 

5.      Access Control:

  • Use only trusted system objects, e.g. server side session objects, for making access authorization decisions
  • Use a single site-wide component to check access authorization. This includes libraries that call external authorization services
  • Access controls should fail securely
  • Deny all access if the application cannot access its security configuration information
  • Enforce authorization controls on every request, including those made by server side scripts, “includes” and requests from rich client-side technologies like AJAX and Flash
  • Segregate privileged logic from other application code
  • Restrict access to files or other resources, including those outside the application’s direct control, to only authorized users
  • Restrict access to protected URLs to only authorized users
  • Restrict access to protected functions to only authorized users
  • Restrict direct object references to only authorized users
  • Restrict access to services to only authorized users
  • Restrict access to application data to only authorized users
  • Restrict access to user and data attributes and policy information used by access controls
  • Restrict access security-relevant configuration information to only authorized users
  • Server side implementation and presentation layer representations of access control rules must match
  • If state data must be stored on the client, use encryption and integrity checking on the server side to catch state tampering.
  • Enforce application logic flows to comply with business rules
  • Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks
  • Use the “referer” header as a supplemental check only, it should never be the sole authorization check, as it is can be spoofed
  • If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate
  • Implement account auditing and enforce the disabling of unused accounts (e.g., After no more than 30 days from the expiration of an account’s password.)
  • The application must support disabling of accounts and terminating sessions when authorization ceases (e.g., Changes to role, employment status, business process, etc.)
  • Service accounts or accounts supporting connections to or from external systems should have the least privilege possible
  • November 2010 Version 2.0 9
  • Create an Access Control Policy to document an application’s business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources

 

6.      Cryptographic Practices:

  • All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system (e.g., The server)
  • Protect master secrets from unauthorized access
  • Cryptographic modules should fail securely
  • All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator when these random values are intended to be un-guessable
  • Cryptographic modules used by the application should be compliant to FIPS 140-2 or an equivalent standard. (See http://csrc.nist.gov/groups/STM/cmvp/validation.html)
  • Establish and utilize a policy and process for how cryptographic keys will be managed

 

7.      Error Handling and Logging:

  • Do not disclose sensitive information in error responses, including system details, session identifiers or account information
  • Use error handlers that do not display debugging or stack trace information
  • Implement generic error messages and use custom error pages
  • The application should handle application errors and not rely on the server configuration
  • Properly free allocated memory when error conditions occur
  • Error handling logic associated with security controls should deny access by default
  • All logging controls should be implemented on a trusted system (e.g., The server)
  • Logging controls should support both success and failure of specified security events
  • Ensure logs contain important log event data
  • Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software
  • Restrict access to logs to only authorized individuals
  • Utilize a master routine for all logging operations
  • Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords
  • Ensure that a mechanism exists to conduct log analysis
  • Log all input validation failures
  • Log all authentication attempts, especially failures
  • Log all access control failures
  • Log all apparent tampering events, including unexpected changes to state data
  • Log attempts to connect with invalid or expired session tokens
  • Log all system exceptions
  • Log all administrative functions, including changes to the security configuration settings
  • Log all backend TLS connection failures
  • Log cryptographic module failures
  • Use a cryptographic hash function to validate log entry integrity
  • November 2010 Version 2.0 10

8.      Data Protection:

  • Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks
  • Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required.
  • Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see “Cryptographic Practices” for additional guidance
  • Protect server-side source-code from being downloaded by a user
  • Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically secure manner on the client side. This includes embedding in insecure formats like: MS viewstate, Adobe flash or compiled code
  • Remove comments in user accessible production code that may reveal backend system or other sensitive information
  • Remove unnecessary application and system documentation as this can reveal useful information to attackers
  • Do not include sensitive information in HTTP GET request parameters
  • Disable auto complete features on forms expected to contain sensitive information, including authentication
  • Disable client side caching on pages containing sensitive information. Cache-Control: no-store, may be used in conjunction with the HTTP header control “Pragma: no-cache”, which is less effective, but is HTTP/1.0 backward compatible
  • The application should support the removal of sensitive data when that data is no longer required. (e.g. personal information or certain financial data)
  • Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users

 

9.      Communication Security:

  • Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the connection and may be supplemented by discrete encryption of sensitive files or non-HTTP based connections
  • TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate certificates when required
  • Failed TLS connections should not fall back to an insecure connection
  • Utilize TLS connections for all content requiring authenticated access and for all other sensitive information
  • Utilize TLS for connections to external systems that involve sensitive information or functions
  • Utilize a single standard TLS implementation that is configured appropriately
  • Specify character encodings for all connections
  • Filter parameters containing sensitive information from the HTTP referer, when linking to external sites
  • November 2010 Version 2.0 11

10.  System Configuration:

  • Ensure servers, frameworks and system components are running the latest approved version
  • Ensure servers, frameworks and system components have all patches issued for the version in use
  • Turn off directory listings
  • Restrict the web server, process and service accounts to the least privileges possible
  • When exceptions occur, fail securely
  • Remove all unnecessary functionality and files
  • Remove test code or any functionality not intended for production, prior to deployment
  • Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then “Disallow” that entire parent directory in the robots.txt file rather than Disallowing each individual directory
  • Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently in different pages in the application
  • Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism
  • If the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar manor or insure that you understand any difference that may exist (e.g. handling of extended HTTP methods)
  • Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks
  • The security configuration store for the application should be able to be output in human readable form to support auditing
  • Implement an asset management system and register system components and software in it
  • Isolate development environments from the production network and provide access only to authorized development and test groups. Development environments are often configured less securely than production environments and attackers may use this difference to discover shared weaknesses or as an avenue for exploitation
  • Implement a software change control system to manage and record changes to the code both in development and production

 

11.  Database Security:

  • Use strongly typed parameterized queries
  • Utilize input validation and output encoding and be sure to address meta characters. If these fail, do not run the database command
  • Ensure that variables are strongly typed
  • The application should use the lowest possible level of privilege when accessing the database
  • Use secure credentials for database access
  • Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted.
  • Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
  • Close the connection as soon as possible
  • Remove or change all default database administrative passwords. Utilize strong passwords/phrases or implement multi-factor authentication
  • Turn off all unnecessary database functionality (e.g., unnecessary stored procedures or services, utility packages, install only the minimum set of features and options required (surface area reduction))
  • November 2010 Version 2.0 12
  • Remove unnecessary default vendor content (e.g., sample schemas)
  • Disable any default accounts that are not required to support business requirements
  • The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)

12.  File Management:

  • Do not pass user supplied data directly to any dynamic include function
  • Require authentication before allowing a file to be uploaded
  • Limit the type of files that can be uploaded to only those types that are needed for business purposes
  • Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient
  • Do not save files in the same web context as the application. Files should either go to the content server or in the database.
  • Prevent or restrict the uploading of any file that may be interpreted by the web server.
  • Turn off execution privileges on file upload directories
  • Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment
  • When referencing existing files, use a white list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead
  • Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs
  • Do not pass directory or file paths, use index values mapped to pre-defined list of paths
  • Never send the absolute file path to the client
  • Ensure application files and resources are read-only
  • Scan user uploaded files for viruses and malware

 

13.  Memory Management:

  • Utilize input and output control for un-trusted data
  • Double check that the buffer is as large as specified
  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string
  • Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space
  • Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions
  • Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)
  • Use non-executable stacks when available
  • Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.)
  • Properly free allocated memory upon the completion of functions and at all exit points
  • November 2010 Version 2.0 13

14.  General Coding Practices:

  • Use tested and approved managed code rather than creating new unmanaged code for common tasks
  • Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands directly to the Operating System, especially through the use of application initiated command shells
  • Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
  • Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions
  • Protect shared variables and resources from inappropriate concurrent access
  • Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage
  • In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible
  • Avoid calculation errors by understanding your programming language’s underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, “not-a-number” calculations, and how your language handles numbers that are too large or too small for its underlying representation
  • Do not pass user supplied data to any dynamic execution function
  • Restrict users from generating new code or altering existing code
  • Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality, as these can introduce new vulnerabilities
  • Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server

 

 

0

Microsoft buys Skype; what does it mean it to the user of Skype?

Microsoft CEO Steve Ballmer and Skype CEO Tony Bates shake hands (Net Picture)

Microsoft CEO Steve Ballmer and Skype CEO Tony Bates shake hands (Net Picture)

Microsoft has been running its Messenger (Windows Live Messenger and MSN Messenger) as a free service for years and it has just bought Skype ; a popular internet telephony application. As a customer i have a number of questions.

  • Now that it has bought Skype what will come of its old messengers?
  • Will they remain free and Skype will become a paid service?
  • Will it up grade Skype, to gain a better competition over Gtalk and Yahoo Messenger?
  • Lets say Skype becomes a paid service, and we can’t blame Microsoft for that (they have invested over $8.5 billion for Christ’s sake?), do you look at Gtalk and Yahoo Messenger as perfect substitutes?

Just thinking;

This feels like perfect time for Open Source to take a stand in internet telephony applications.

Quite a lot of questions here and there, but as a consumer I always look for the best and affordable product. So let’s see where this leads us; we can’t without admitting that Skype is a great application, Congratulations to Microsoft.

Microsoft buys Skype at $8.5 billion(Net Picture)

Microsoft buys Skype at $8.5 billion (Net Picture)

Beneth

13/05/2011

4

We have made 7,342 hits

Counting 7342 hits!


We have made 7,342 hits, and we are still counting.

We started from 0 together and now we have hit 7000+
Am really humbled.

All i can say is, thank you.
Thank you….
And may God bless You.


Lots of love,

Benie.

0

Thank you Friends

Akoola’s Blog has got 4000+ hits,
and all thanks i give to you.

I thank my brother Kiiza, aka. kabonde who introduced to wordpress.com …
by then i was thinking of joining blog spot.

I loved the templates of wordpress,
the colors, the format, the layout.

I can say, it’s cool enough for me.

Mostly,
i thank God for the words he has put at in my mind,
and the desire to share my thoughts,
and imaginations.

Other wise,
i would not have said anything.
Lets keep it on,

Thanks a lot.
Benie M,
a.k.a Akoola.

1

Sweet Voice

I can here a voice
It’s from a far,
It’s like in my mind.

It’s a sweet voice,
Filling the sky with love,
But it just a voice.

It comforts the lonely,
Celebrates with achievers,
Feels the heart with joy.

It’s a sweet voice
It’s a radio
Reaching out to every one.

This radio with a sweet voice,
Feeling the sky with love,
Reaching out to it’s unknown friends.

Tune to the radio,
Listen to the sweet voice
Experience the beauty of a voice.

By Benie’
03-07-2008

0

10 dirty little secrets you should know about working in IT

If you are preparing for a career in IT or are new to IT, many of the “dirty little secrets” listed below may surprise you because we don’t usually talk about them out loud. If you are an IT veteran, you’ve probably encountered most of these issues and have a few of your own to add — and please, by all means, take a moment to add them to the discussion. Most of these secrets are aimed at network administrators, IT managers, and desktop support professionals. This list is not aimed at developers and programmers — they have their own set of additional dirty little secrets — but some of these will apply to them as well.

10.) The pay in IT is good compared to many other professions, but since they pay you well, they often think they own you

Although the pay for IT professionals is not as great as it was before the dot-com flameout and the IT backlash in 2001-2002, IT workers still make very good money compared to many other professions (at least the ones that require only an associate’s or bachelor’s degree). And there is every reason to believe that IT pros will continue to be in demand in the coming decades, as technology continues to play a growing role in business and society. However, because IT professionals can be so expensive, some companies treat IT pros like they own them. If you have to answer a tech call at 9:00 PM because someone is working late, you hear, “That’s just part of the job.” If you need to work six hours on a Saturday to deploy a software update to avoid downtime during business hours, you get, “There’s no comp time for that since you’re on salary. That’s why we pay you the big bucks!”

9.) It will be your fault when users make silly errors

Some users will angrily snap at you when they are frustrated. They will yell, “What’s wrong with this thing?” or “This computer is NOT working!” or (my personal favorite), “What did you do to the computers?” In fact, the problem is that they accidentally deleted the Internet Explorer icon from the desktop, or unplugged the mouse from the back of the computer with their foot, or spilled their coffee on the keyboard.

8.) You will go from goat to hero and back again multiple times within any given day

When you miraculously fix something that had been keeping multiple employees from being able to work for the past 10 minutes — and they don’t realize how simple the fix really was — you will become the hero of the moment and everyone’s favorite employee. But they will conveniently forget about your hero anointment a few hours later when they have trouble printing because of a network slowdown — you will be enemy No. 1 at that moment. But if you show users a handy little Microsoft Outlook trick before the end of the day, you’ll soon return to hero status.

7.) Certifications won’t always help you become a better technologist, but they can help you land a better job or a pay raise

Headhunters and human resources departments love IT certifications. They make it easy to match up job candidates with job openings. They also make it easy for HR to screen candidates. You’ll hear a lot of veteran IT pros whine about techies who were hired based on certifications but who don’t have the experience to effectively do the job. They are often right. That has happened in plenty of places. But the fact is that certifications open up your career options. They show that you are organized and ambitious and have a desire to educate yourself and expand your skills. If you are an experienced IT pro and have certifications to match your experience, you will find yourself to be extremely marketable. Tech certifications are simply a way to prove your baseline knowledge and to market yourself as a professional. However, most of them are not a good indicator of how good you will be at the job.

6.) Your nontechnical co-workers will use you as personal tech support for their home PCs

Your co-workers (in addition to your friends, family, and neighbors) will view you as their personal tech support department for their home PCs and home networks. They will e-mail you, call you, and/or stop by your office to talk about how to deal with the virus that took over their home PC or the wireless router that stopped working after the last power outage and to ask you how to put their photos and videos on the Web so their grandparents in Iowa can view them. Some of them might even ask you if they can bring their home PC to the office for you to fix it. The polite ones will offer to pay you, but some of them will just hope or expect you can help them for free. Helping these folks can be very rewarding, but you have to be careful about where to draw the line and know when to decline. For help, take a look at TechRepublic’s free download “Ten ways to decline a request for free tech support.”

5.) Vendors and consultants will take all the credit when things work well and will blame you when things go wrong

Working with IT consultants is an important part of the job and can be one of the more challenging things to manage. Consultants bring niche expertise to help you deploy specialized systems, and when everything works right, it’s a great partnership. But you have to be careful. When things go wrong, some consultants will try to push the blame off on you by arguing that their solution works great everywhere else so it must be a problem with the local IT infrastructure. Conversely, when a project is wildly successful, there are consultants who will try to take all of the credit and ignore the substantial work you did to customize and implement the solution for your company.

4.) You’ll spend far more time babysitting old technologies than implementing new ones

One of the most attractive things about working in IT is the idea that we’ll get to play with the latest cutting edge technologies. However, that’s not usually the case in most IT jobs. The truth is that IT professionals typically spend far more time maintaining, babysitting, and nursing established technologies than implementing new ones. Even IT consultants, who work with more of the latest and greatest technologies, still tend to work primarily with established, proven solutions rather than the real cutting edge stuff.

3.) Veteran IT professionals are often the biggest roadblock to implementing new technologies

A lot of companies could implement more cutting edge stuff than they do. There are plenty of times when upgrading or replacing software or infrastructure can potentially save money and/or increase productivity and profitability. However, it’s often the case that one of the largest roadblocks to migrating to new technologies is not budget constraints or management objections; it’s the veteran techies in the IT department. Once they have something up and running, they are reluctant to change it. This can be a good thing because their jobs depend on keeping the infrastructure stable, but they also use that as an excuse to not spend the time to learn new things or stretch themselves in new directions. They get lazy, complacent, and self-satisfied.

2.) Some IT professionals deploy technologies that do more to consolidate their own power than to help the business

Another subtle but blameworthy thing that some IT professionals do is select and implement technologies based on how well those technologies make the business dependent on the IT pros to run them, rather than which ones are truly best for the business itself. For example, IT pros might select a solution that requires specialized skills to maintain instead of a more turnkey solution. Or an IT manager might have more of a Linux/UNIX background and so chooses a Linux-based solution over a Windows solution, even though the Windows solution is a better business decision (or, vice versa, a Windows admin might bypass a Linux-based appliance, for example). There are often excuses and justifications given for this type of behavior, but most of them are disingenuous.

1.) IT pros frequently use jargon to confuse nontechnical business managers and hide the fact that they screwed up

All IT pros — even the very best — screw things up once in a while. This is a profession where a lot is at stake and the systems that are being managed are complex and often difficult to integrate. However, not all IT pros are good at admitting when they make a mistake. Many of them take advantage of the fact that business managers (and even some high-level technical managers) don’t have a good understanding of technology, and so the techies will use jargon to confuse them (and cover up the truth) when explaining why a problem or an outage occurred. For example, to tell a business manager why a financial application went down for three hours, the techie might say, “We had a blue screen of death on the SQL Server that runs that app. Damn Microsoft!” What the techie would fail to mention was that the BSOD was caused by a driver update he applied to the server without first testing it on a staging machine.

From: http://blogs.techrepublic.com

Am sure you have done or experienced some.

Akoola