When I was blabbering about "organic architecture" and "organic programming" concepts a short while ago, this is one example. These are macro objects. In decades from now, they will have this shrunken down much smaller. Imagine where this could lead us.
Sunday, 9 October 2011
Friday, 7 October 2011
The consulting firm I work for has quite a few job openings in the Hampton Roads area that we are trying to fill. If you live in or near the cities of Norfolk, Chesapeake, Virginia Beach, or Suffolk, and are interested in any of these positions, contact me at ds0934 (at) gmail (dot) com, and attach your resume in MS Word format. Use the subject line "IT Positions" so I don't tag it as spam.
- Package/Workstation engineer - (Wise Installer or AdminStudio, SCCM, Windows 7, etc.)
- Project Team Engineer - (VMware, Windows, Exchange, AD, light Cisco, SAN)
- Help Desk Analyst (Windows 7/Office/Light Networking/Great Client phone skills)
- Macintosh Engineer
- Engineer for option to hire for large client in Suffolk (Windows 2008, Exchange, Cisco, Light VMware)
- Engineer for option to hire for large client in Virginia Beach (Windows 2008, Exchange 2007/2010, AD, VMware)
- Engineer for option to hire for client in Newports News. Will be at shipyard. (Windows, Linux, Light Networking, etc.) CAD experience is nice but not required.
Thursday, 6 October 2011
How many times have you uninstalled a software product only to find out later that it left traces of its existence all over your poor computer? Part of the work of a software packager (or rather: repackager) is to perform forensic analysis of the footprint of an application at the time of installation, after being used, and after being uninstalled. The goal is always to get the computer back to a state as if the application had never been installed, but without causing issues with the operating system or other applications. Rather than try to split this over XP, Vista and Windows 7, I'm only talking about 7 here. I don't give a crap about XP or Vista anymore, sorry. If the %name% stuff confuses you, just open a CMD window, type in SET and press Enter to see what I'm talking about.
The Obvious
- %ProgramFiles%
- %WinDir%\System32
- %CommonProgramFiles%
- %AllUsersProfile% (note: This is a Symbolic Link to %ProgramData%, same place)
- %ProgramData%
- %Temp%
- HKLM\SOFTWARE\<vendor-or-product>
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
The Not-So-Obvious
- 64-bit Systems
- %ProgramFiles(x86)%
- %CommonProgramFiles(x86)%
- HKLM\Software\Wow6432Node\...
- %LocalAppData%
- %SystemDrive%\Users\Default (note: "Default User" is a JUNCTION to "Default", same place)
- Services
- DCOM configuration settings
- WMI / CIM namespaces
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (and RunOnce)
- HKLM\SOFTWARE\Microsoft\Active Setup\...
- HKLM\SOFTWARE\ODBC\...
- HKEY_CLASSES_ROOT\...
- HKLM\SYSTEM\CurrentControlSet\...
- HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
- %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup
This is not a complete list. Some applications crap in more places than these. But hopefully this gives you a rough idea of places to look when something gets left behind and things are just not quite right as a result.
Tools
Some of the tools that can come in handy to help investigate what an application does to a computer are as follows:
- Virtualization: VMware Player, VMware Workstation, Virtual Box, Hyper-V
- Sysinternals: Process Explorer, AutoRuns, Process Monitor
- CMD: DIR /AH /AS
- InstallShield Repackager (snapshot results)
The most common and most detrimental mistakes that seem to occur again and again. I'm not saying you need to "master" all of these, but you should be familiar enough with all of these aspects to be able to explain them to your grandmother. Hopefully you strive to apply these in your daily work.
- Not Understanding Programming Basics
- Decision Branching (If / Then / Else / Select /Switch / Cond / ElseIf, etc.)
- Boolean Logic (And, Not, Or, etc.)
- Functions, Sub-Routines, Lambda Expressions
- Iteration and Recursion (While, Do, For, Apply, Mapcar, etc.)
- Variable Scopes (local, private, global, public, etc.)
- Not understanding all of the Data Types for a given language
- Not understanding String Behaviors (for given language)
- Not understanding File Streams
- Ignoring ERROR/EXCEPTION HANDLING (Gaa!!!! GD IT!!!)
- Not Documenting source code (it ain't just for others, it helps you as well, especially when you go back to fix something a year later)
- Modularity / Code Reuse
- Not Understanding Databases
- Ignorant of Table Structures and Data Types
- Ignorant of Constraints
- Normalization !!!!!!!!! God damn it! Normalize your fucking tables!!!
- Views and Stored Procedures
- Using MS-Access to build applications (GD IT!!!!!!! teeth gnashing)
- Excel is NOT a database!
- Not Understanding User Context
- Assuming users have administrator rights (kill the developer on sight!)
- Not understanding Multi-user / Shared computer environments
- Not understanding Terminal Services / Server Shared environments
- Not understanding Service / Proxy accounts
- Not Understanding the Installation (and Uninstall) Process
- Not following the documented guidelines (TechNet, MSDN)
- Not providing a Silent/Unattended installation option
- Not providing a Silent/Unattended Uninstallation option
- Not using MSI-based installers (Windows only) - a setup bootstrap is ok, but building your own installer is just stupid as shit. And stop with the no-name bullshit setup packagers, just buy Wise or InstallShield and do it right, mmmkay?
- Ignoring Cohesion and Consistency
- Installation scatters crap all over the place, rather than keeping it collocated logically
- Application stores state data in too many locations (registry and files, and ...)
- Forgetting to REFACTOR your code (using the rollback method, where you revisit project "A" after finishing product "C" to apply what you learned since)
- Ignoring common naming conventions. Name your code files, functions, variables, registry keys, event entries, database names, tables, views, procedures, services and everything CONSISTENTLY! If you don't care enough to make your code look like it works as an integral army of awesomeness, what else don't you care about? Making it work properly?!
- Becoming Locked into One Language
- Learning and Using ONE language is like eating with only a fork. No spoon or knife? It's like trying to rebuild a car engine with only a screw driver. Languages are tools. The more you learn and apply, the broader your skills, understanding and wisdom about methods, approaches, and quality.
- Never assume an "old" language has nothing to offer. There are still plenty of situations where an "old" BAT script will work more efficiently than VBscript or PowerShell. Where an INI file will work more efficiently than an XML file or a database table query.
- Arguing in defense of ONE language above all others. Within the context of a particular project or contract, this is acceptable. However, in the global scope of programming, this is the sign of a complete idiot.
- Buying books on one language before reading books on general programming practices and theory is just stupid. This is like reading a book on 1001 ways to use a fork to eat. Why not read up on eating, then learn about the tools, that way you understand why you're using the fork, and not just how to use it.
What can you do about it?
- Read Books on Programming topics (not just an "Unleashed" book on your favorite language)
- Read some useful Blogs about programming
- Go to School (a university, not a for-profit tech school)
- Join MSDN or TechNet or something similar (and use it!)
- Meet with other programmers - ESPECIALLY programmers that work with other languages, database engineers and administrators, network engineers, etc.
Tuesday, 4 October 2011
I doubt any of you will read this one to the end, and I can't blame you. But I have to say that this is probably one of my best articles so far. It's one that I'm fairly passionate about and it shows in my verbosity. I apologize for torturing your eyeballs in advance, but I must go on.
For many of you, this scenario should sound pretty familiar:
A large corporate business evolves over decades to the point where they decide it makes sense to centralize their IT operations. They create a new department and appoint a CTO or CIO and staff the various functions. Prior to this, it was common to find each department building and maintaining their own unique software applications to solve their own internal business needs, aka "line of business" applications ("LOB" for short). In decades past, it was dBase or FoxPro. In more recent times it's been Microsoft Access or Excel. Quite often, it involves VBA code. Lots and lots of VBA code.
The centralized IT department strives to gather all of the LOB applications and apply some centralized procedures to maintaining it. Maybe the company is trying to be ISO or CMMI compliant, or maybe ITIL, or whatever. Who knows. In any case, the MBA mindset comes to the logical conclusion that redudant job roles are expensive and inefficient, especially when one person in Finance is building roughly the same application as the person in Sales. These isolated, parallel and typically redundant efforts have no incentive or desire to coordinate efforts with other departments due to politics and funding, so they march on unrestricted for years.
When IT finally gains control of a few of the key LOB applications, they apply common ITIL or CMMI procedures on change control, which invariably slows down the process of implementing updates. The LOB folks quickly grow tired of this, and eventually pull away from IT to continue building their own applications. The cycle continues.
This is often referred to as a "NO-WIN SITUATION", because that's exactly what it is.
The top management folks are left with two options:
- Ignore it and leave the fighting to the lower level managers
- Stress out trying to make a decision over which is the lesser evil: inefficiency or inefficiency.
The two greatest risks facing them are:
- Allowing the redundant waste of time and resources to grow unchecked (because it's NEVER really checked) and allow inconsistent results to spread. The practice increasingly melds the company core business processes to hundreds of tiny little tools built by people that have worked themselves into a position of necessity (cant' fire them or you risk being stuck with a broken tool and a busted business process)
- Forcing the LOB apps under the control of the IT department, becoming painfully slow at responding to surge-capacity, and frequent requirements changes. Everything must now be vetted, developed, tested and implemented under the new procedures. No more "walk-up" requests. No more Summer intern kid-turned-full-time-developer to handle your needs. LOB requests now get routed through a load-sharing process to "resources" which share their precious time with other (possibly competing) LOB requests.
Ugliness. Bad feelings. Animosity. All that kind of stuff.
This is one of the reasons I F-ING HATE MICROSOFT ACCESS
The product itself is not bad or evil. Fire isn't bad, when used properly. Each serves a noble purpose. But fires created by a small group of trained professionals is one thing. Handing every person in a 10 mile radius a can of gasoline and a box of matches is a little different. Server backended applications are like the trained professionals. Microsoft Access is like a truckload of gasoline cans and matches being handed out like rice bags from a UN truck in Rwanda.
The most common scenario today involves this vicious cycle of stupidity:
- The Sales department asks a promising Summer intern to build them an uber sales tracking app. Uber-brainy intern cracks open a "Access VBA Unleashed" book, and builds the new application in MS Access 2000 using lots of VBA.
- Years later, the company decides to take advantage of volume licensing and buys into a SELECT or ENTERPRISE AGREEMENT contract to get upgrades more cheaply. The Company recieves licensing for Office 2010 and wants to upgrade all computers ASAP.
- The Sales department cries that Access 2010 will break their LOB app. They cry to upper management. IT is ordered to put the upgrade plans on hold.
- The IT department now decides on one of two courses of action:
- Dedicate several developers to re-developing the application to work in Access 2010, but they don't understand the LOB requirements or logic, so they have to work closely with the Sales department to gain better understanding. They also have to decide how to address deprecated functionality (from Access/VBA 2000 to 2010), and incorporate new features, or if there is even enough time to do that, or just patch it up and make it work.
- Dedicate several developers to shoehorn the old application to work via the Access 2000 runtime engine, if that even works (sometimes it does, sometimes it doesn't). This often becomes a mess, with file associations getting corrupted and interaction issues with other third-party applications.
- The plan to deploy Office 2010 is now sidelined until they can adequately resolve this dilemma.
- By the time a solution is reached, Office 2012 is released and the process repeats
Either way, it ends up being a long, drawn-out waste of time, money and effort. Sure, it can be argued that it's not a waste because it's provides (hopefully) a workable solution. But if the entire problem COULD have been avoided by adopting proven practices, isn't that ultimately a waste?
A database is a database. It should be used as a database, not as an end-user application platform. Client/Server or web-based interfaces would easily decouple the functionality from the data store. Then if the only thing that changes are the database connection parameters, you don't have to rewrite the entire application. In many mature development environments, this is considered programming 101.
You probably won't believe me, but I actually do get sick of hearing myself talk and get queazy reading my own drivel. But painful as it may be, I must go here...
Over-Caffeinated Rant (deep inhale, and....)
I haven't really delved into the virtues of decoupled business logic in n-tier applications architecture. There's an enormously powerful incentive to following this time-tested and well-proven approach, which is along the same lines of logic as multi-stage code compilation, assembly line production, and zone defense in team sports. That is, that compartmentalizing certain logical blocks of functionality make those blocks portable and flexible. It makes them more easily (and more affordably) adaptable to future changes. You know, those future changes that are quite often unforeseeable and unpredictable? It also tends to make those newly defined blocks more efficient, both in construction and execution performance.
But things like n-tier business logic and decoupling are rarely familiar terms to the Summer intern who happens to dig tinkering with VBA (or VSTO) within Office applications like Excel and Access. To them, it's just fun to code, and who can blame them? How do you effectively convince this wunderkind teenager that "fun" isn't as "cool" as decoupling your code and applying standard design prinicipals to it before ever punching a key or clicking a mouse? It's a serious conundrum for businesses of all sizes, but particularly insidiuos and debilitating for larger corporate behemoths due to their scales of inefficiency at all levels. Who is the best equipped, and motivated to insert themselves into this vicious chain reaction and disrupt it entirely: IT, LOB stake-owners, or senior management? IT rarely has the global authority to stomp out such wildfires alone. LOB stake-owners rarely have the global incentive. Senior management doesn't give a shit because that's why they hired mid-level management to insulate them from. When LOB stake-owners are coupled with mid-level management (often one and the same), it's a done deal: nothing is going to improve. This is the most common scenario in modern corporations today. A Catch-22.
My coffee just ran out.
Monday, 3 October 2011
If you're using Microsoft System Center Configuration Manager, you're well aware that there's a lot of moving parts. It often seems like staring into the back of an opened pocket watch, being awed by the mass of tiny gears working in such precision. If you've been working with it for a long time, you're also likely aware that hiccups occur and that they tend to happen in certain places more than others. Most CM administrators I know become familiar with particular groups of issues and have developed their own personal "solution" practices to troubleshoot and resolve them.
Package Configuration - check the data source settings, and the permissions on the folders and shares also. Some packages don't need to be broadcast over the DP shares since they can't install from them at zero hour. For example: AutoCAD network deployments, which contain a hard-coded UNC reference to the original administrative share location. Yet it's very easy to let it be replicated, slowly (lots of content), and eat up a lot of disk space, when the installations will simply run back to the original location to pull installation content. Tip: Use a script to call the installation, where only the script is replicated to the DP shares, but make sure the original share has permissions configured properly to allow the CM client/agent to install it via the advertisement.
Program Configuration - verify the command you entered as well as any additional parameters (aka "arguments"). Also, verify the disk space requirements and runtime limit value. If you specify too large of values, some clients may fail the requirements assessment and the program won't run. This will show up in the advertisement status details web reports for each client. Watch out for quoted string values and special characters also.
Client Cache - the client cache can be a common source of headaches when deploying packages, especially when the same package has been updated several times, refreshed on the DPs, and re-run multiple times (usually to fix late-discovered issues). It's not uncommon to have to manually clear out the previous package cache remains on a problem client. It's not uncommon to have to clear out other/older deployments as well, just to free up total cache space. Double check the client cache size setting also, but be careful about bumping the size up without carefully considering the ramifications as well.
WMI issues - as with many client health improvements in Configuration Manager 2012, I'm looking forward to seeing this issue go away. You may be aware of the situations where you end up having to run a repair operation on the WMI stack in order to get a particular client to communicate with the site again. Ugh.
Maintenance Windows - if you use maintenance windows for your CM site, be sure to evaluate how your software updates are being deployed and how it impacts other packages as well. Sometimes a small adjustment is all it takes to make it work, or not work at all.
Network Issues - with all the incredible power and complexity of Configuration Manager, it can't do anything if the network isn't reliable.
Anti-Virus Hurdles - yep. sometimes anti-virus products can get in the way with deployments. Quite often by ripping out just one or two key components during the installation process (or right after) and crippling the application. If an application works fine in your test environment, but not on the production environment, check the antivirus scan logs and quarantine reports.
Prerequisites - many software products expect things to be at least up to a certain baseline before they can install. Sometimes they will also take care of filling in any missing requirements. Sometimes they can't, and when they can't, they fail to install. This should be addressed during testing, but sometimes things get missed. Other times it stems from human communication issues. You might have asked the desktop support team if .NET 4.0 was on every client and they might have said it was, when in fact it was only on some computers, and you didn't bother to verify this yourself. There you go.
Custom Packaging - if you (or someone you work with) created the installation source internally, verify any pre-requisites: operating system, version, service pack level, .NET or IE requirements, 32-bit or 64-bit, and so on. This should all be hammered out during testing, but sometimes things get missed.
Square 1 - Level 0 - if the application you're looking to deploy needs to be part of every desktop and laptop in your organization, don't forget to consider making it part of your standard image deployment as well. If you use MDT or Configuration Manager OSD to handle your client provisioning, add your application there as well. That way it's one less thing to push over the network later on. It's also quite a bit less complext to implement and troubleshoot during the base imaging process than when deploying over your network environment later.
Summary
I must say that you shouldn't construe this to be a ridicule of Configuration Manager 2007 at all. Configuration Manager is a fantastic product. But like all products that serve a similar role, there's a lot of intricate things going on in the background, and a lot of things depend on how you configure and maintain them as well. Many CM implementations experience only minor hiccups, while others have more frequent issues. A lot of that is dependent upon how well the environment was designed, implemented and maintained. It also depends on how well the clients are maintained, but software installers themselves are often the wild variable in the equation.
I'm sure there's more to add to this list, but this is enough to jot down for now. For more insight into Configuration Manager and package deployments, check out some of the links below:
- MyItForum
- Rod Trent - Twitter - Google+
- Brian Tucker (blog) - Google+
- Chris Nackers (blog)
- Brian Mason (MNSCUG) - Google+
- Cliff Hobbs (blog)
- Sherri Kissinger (blog) - Google+
- Jason Sandys (blog)
- Johan Arwidmark (TrueSec) - Twitter - Google+
- Configuration Manager Support Team Blog
- AppDeploy.com
I know I haven't even come close to covering everyone that I should, but if you check out these folks, and see who they link to, you should end up with a pretty good list of amazing and interesting people to learn from.
Saturday, 1 October 2011
Subscribe to:
Posts (Atom)
