Friday, December 31, 2010
Thursday, December 30, 2010
Wednesday, December 29, 2010
Tuesday, December 28, 2010
Monday, December 27, 2010
Tuesday, December 21, 2010
Monday, December 20, 2010
Sunday, December 19, 2010
Friday, December 17, 2010
Tuesday, December 14, 2010
Monday, December 13, 2010
Sunday, December 12, 2010
Friday, December 10, 2010
Thursday, December 9, 2010
Monday, December 6, 2010
Friday, December 3, 2010
Tuesday, November 30, 2010
Monday, November 29, 2010
Friday, November 26, 2010
Wednesday, November 24, 2010
Monday, November 22, 2010
Saturday, November 20, 2010
Friday, November 19, 2010
Thursday, November 18, 2010
Wednesday, November 17, 2010
Tuesday, November 16, 2010
Monday, November 15, 2010
Friday, November 12, 2010
Thursday, November 11, 2010
Wednesday, November 10, 2010
Tuesday, November 9, 2010
Monday, November 8, 2010
Sunday, November 7, 2010
Friday, November 5, 2010
Thursday, November 4, 2010
Tuesday, November 2, 2010
Monday, November 1, 2010
Saturday, October 30, 2010
Thursday, October 28, 2010
Wednesday, October 27, 2010
Exciting project coming to fruition
The Social Media Health Network, a service of the Mayo Clinic Center for Social Media, will provide access to tools, resources and guidance for organizations and individuals that want to apply social media in health and health care. The Network will offer different membership options, including free and paid memberships.
The charter members of the Social Media Health Network are:
- Inova Health System, Reston, Virginia, USA
- Mission Health Care, Asheville, North Carolina, USA
- Mayo Clinic, Rochester, Minnesota, USA
- Swedish Medical Center, Seattle, Washington, USA
- Radboud University Nijmegen Medical Centre, Nijmegen, Netherlands
Technical Notes
I developed the site in Drupal, using off the shelf modules for functionality, when available. Modifications to default functionality and 'look and feel' were made to better suit the health care community. On the back end, the site is served from Amazon EC2, utilizing Pressflow, Memcahce and Apache SOLR to provide quick response and fast data searches. PHPMyAdmin, ISPConfig and Traq are used for customer and server support.
Tuesday, October 26, 2010
Monday, October 25, 2010
Tuesday, October 19, 2010
Monday, October 18, 2010
Saturday, October 16, 2010
Friday, October 15, 2010
Thursday, October 14, 2010
Monday, October 11, 2010
Thursday, October 7, 2010
Monday, October 4, 2010
Sunday, October 3, 2010
Saturday, October 2, 2010
Friday, October 1, 2010
Thursday, September 30, 2010
Tuesday, September 28, 2010
Monday, September 27, 2010
Friday, September 24, 2010
Drupal for Health Care -- You Bet!
Drupal is an open source, content management system that provides a framework for developing complex sites. That's right... open source, no charge. It's easy to fear a no cost option, but Drupal has thousands of developers creating and maintaining the framework.
Drupal is extensible. Through the use of plug-in modules, developers can add hundreds of functions to the core framework. There is some great functionality that can be added to Drupal for health care -- groups, micro blogging, shopping carts, slideshows, project management, and social media widgets, just to name a few. And if you are concerned about SEO, there are Drupal modules that will help your site move up the search engine index.
Because Drupal is open source, developers have access to all the source code. That means they can tailor functionality to meet the needs of the provider. The web layout code is included as well, so the 'look and feel' of the site can be modified as the provider wishes.
Drupal also contains utility tools to monitor the health of the site and to let you know when updates to the core and your modules are available.
Drupal makes it easy to put together functional websites quickly. It makes it easy to create content of different types, including blogs, stories, videos and images. If you are a provider looking to develop a new web presence, look at Drupal, and maybe even save a few dollars in the process.
Thursday, September 23, 2010
Wednesday, September 22, 2010
Monday, September 20, 2010
Friday, September 17, 2010
Thursday, September 16, 2010
Monday, September 13, 2010
Thursday, September 9, 2010
Wednesday, September 8, 2010
Tuesday, September 7, 2010
Monday, September 6, 2010
Sunday, September 5, 2010
Saturday, September 4, 2010
Wednesday, September 1, 2010
Monday, August 30, 2010
Sunday, August 29, 2010
Saturday, August 28, 2010
Wednesday, August 25, 2010
Tuesday, August 24, 2010
Friday, August 20, 2010
Thursday, August 19, 2010
Wednesday, August 18, 2010
Blount Punches Again
Blount Caps Night Practice by Punching Teammate
Aug 18, 11:34 PM (ET)
By TERESA M. WALKER
NASHVILLE, Tenn. (AP) -This punch won't be so costly for LeGarrette Blount.
The rookie running back capped off a feisty night practice for the Tennessee Titans with a short punch to the helmet of defensive end Eric Bakhtiari a few moments after having his own helmet ripped off for the second time in as many plays.
Blount had just returned to the Titans on Wednesday night after being excused since Sunday for personal reasons. He was carrying the ball in a drill near the goal line when his helmet came off, and he kept his feet moving toward the end zone.
The play ended with some pushing and shoving, then Blount threw a right into Bakhtiari's facemask. Blount quickly talked to coach Jeff Fisher before leaving the field.
"He apologized, and I said he didn't have to apologize," Fisher said. "It's football. It's training camp."
Blount was suspended by the University of Oregon for eight games of last season for punching Boise State defensive end Byron Hout after a game on Sept. 3. Without much of a senior season, Blount went undrafted.
The Titans, having traded away LenDale White, brought in Blount as a free agent.
On the play that sparked Wednesday's scuffle, Blount said his helmet had been intentionally pulled off the play before. A new NFL rule going into effect this season stops the play when a player's helmet comes off. Then his helmet came off again. Blount said he apologized to Fisher because he had promised the coach his fighting days were behind him.
"That was my past. It just came up again. I got into one of those situations where the defense pushed me too far. With training camp and everything going the way it is and being as intense as it is and me being a rookie, it was just something I shouldn't have done. But I did it," Blount said.
Fisher downplayed the punch.
"His past is his past. Is that the first punch you've seen in camp this year? No. I'm not disappointed whatsoever. I have great confidence in the young man that he learned from his mistake, and he's very competitive. That's why we brought him in here is to watch him run the football like that," Fisher said.
Bakhtiari, with a towel draped over his head, declined to comment to reporters in the locker room.
The Titans originally had been scheduled to practice outdoors under the lights at LP Field in a closed session. Heavy rains predicted to drop at least 4 inches of rain onto the field prompted Fisher to move the practice back to the team's headquarters, and they worked inside under the lights.
It was an intense physical practice with Vince Young yelling at receivers not getting to balls, and he even got popped himself once by safety Michael Griffin. Fisher said it was the kind of session his team needed during essentially the last long week of training camp.
The Titans' preseason opener is Monday against Arizona, then the teams hold a joint practice two days later before Tennessee wraps up training camp.
Fullback Ahmard Hall called Blount's reaction just the intensity of training camp.
"If anybody else was to get mad, there wouldn't be a question. It would just be a guy getting mad. LeGarrette Blount gets mad, everybody wants to bring up his past. Guys pushed him. He reacted. It has nothing to do with what happened to him in the past," Hall said.
Tuesday, August 17, 2010
Monday, August 16, 2010
Sunday, August 15, 2010
Saturday, August 14, 2010
Friday, August 13, 2010
Tuesday, August 10, 2010
Monday, August 9, 2010
Wednesday, August 4, 2010
Tuesday, August 3, 2010
Monday, August 2, 2010
Sunday, August 1, 2010
Saturday, July 31, 2010
Thursday, July 29, 2010
Wednesday, July 28, 2010
Tuesday, July 27, 2010
Monday, July 26, 2010
Sunday, July 25, 2010
Saturday, July 24, 2010
Friday, July 23, 2010
Wednesday, July 21, 2010
Monday, July 19, 2010
Saturday, July 17, 2010
Friday, July 16, 2010
Thursday, July 15, 2010
Tuesday, July 13, 2010
Monday, July 12, 2010
Saturday, July 10, 2010
Friday, July 9, 2010
Thursday, July 8, 2010
Tuesday, July 6, 2010
Monday, July 5, 2010
Sunday, July 4, 2010
Saturday, July 3, 2010
Friday, July 2, 2010
Thursday, July 1, 2010
Wednesday, June 30, 2010
Tuesday, June 29, 2010
Saturday, June 26, 2010
Friday, June 25, 2010
Wednesday, June 23, 2010
Tuesday, June 22, 2010
Monday, June 21, 2010
Sunday, June 20, 2010
Saturday, June 19, 2010
Friday, June 18, 2010
Thursday, June 17, 2010
Wednesday, June 16, 2010
Tuesday, June 15, 2010
Monday, June 14, 2010
Thursday, June 3, 2010
Pragmatic Software Development Tips
Extracted From The Pragmatic Programmer
by Andrew Hunt and David Thomas. Copyright 2000, Addison Wesley.
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
Involve your users in determining the project’s real quality requirements.
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Design components that are self-contained, independent, and have a single, well-defined purpose.
Tracer bullets let you home in on your target by trying things and seeing how close they land.
Design and code in your user’s language.
Use experience you gain as you implement to refine the project time scales.
Use the shell when graphical user interfaces don’t cut it.
Source code control is a time machine for your work—you can go back.
Take a deep breath and THINK! about what could be causing the bug.
Prove your assumptions in the actual environment—with real data and boundary conditions.
Code generators increase your productivity and help avoid duplication.
Use contracts to document and verify that code does no more and no less than it claims to do.
Assertions validate your assumptions. Use them to protect your code from an uncertain world.
Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
Implement technology choices for an application as configuration options, not through integration or engineering.
Exploit concurrency in your user’s workflow.
Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.
Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
Get a feel for how long things are likely to take before you write code.
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
Test ruthlessly. Don’t make your users find bugs for you.
Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
When faced with an impossible problem, identify the real constraints. Ask yourself: ``Does it have to be done this way? Does it have to be done at all?’‘
Don’t fall into the specification spiral—at some point you need to start coding.
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
A shell script or batch file will execute the same instructions, in the same order, time after time.
‘Nuff said.
Identify and test significant program states. Just testing lines of code isn’t enough.
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
Come to understand your users’ expectations, then deliver just that little bit more.
Turn off the autopilot and take control. Constantly critique and appraise your work.
Fix bad designs, wrong decisions, and poor code when you see them.
Don’t get so engrossed in the details that you forget to check what’s happening around you.
Make learning a habit.
There’s no point in having great ideas if you don’t communicate them effectively.
If it’s easy to reuse, people will. Create an environment that supports reuse.
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
Estimate before you start. You’ll spot potential problems up front.
Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
You spend a large part of each day working with text. Why not have the computer do some of it for you?
Software can’t be perfect. Protect your code and users from the inevitable errors.
A dead program normally does a lot less damage than a crippled one.
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
Avoid coupling by writing ``shy’’ code and applying the Law of Demeter.
Program for the general case, and put the specifics outside the compiled code base.
Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.
Gain flexibility at low cost by designing your application in terms of models and views.
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.
Start thinking about testing before you write a line of code.
Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
It’s the best way to gain insight into how the system will really be used.
Create and maintain a single source of all the specific terms and vocabulary for a project.
You’ve been building experience all your life. Don’t ignore niggling doubts.
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.
Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.
Tests that run with every build are much more effective than test plans that sit on a shelf.
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
Documentation created separately from code is less likely to be correct and up to date.
Craftsmen of an earlier age were proud to sign their work. You should be, too.
Tuesday, April 13, 2010
Danger! Danger! The Warning Signs of a Failing Project by Ty Kiisel
Although most projects don't have a B-9 robot, there are warning signs that identify a troubled project early enough to do something about it.
The earliest signs that a project is in trouble are hard to measure objectively, but are relatively easy to spot, if you're watching:
- Lack of interest: Whether it's a lack of interest within the project team or among project stake holders, it's often demonstrated by people not showing up for meetings, a lack of active participation and feedback, or a poorly energized user base. This is an early-warning sign of a project in trouble.
- Poor communication: If nobody is communicating, including stakeholders, team members, and end users, there could be a problem.
- Lack of velocity: Projects should always be moving forward. The best way to keep a good velocity is to divide your project into small deliverables at frequent intervals. If the project isn't moving forward, it's likely in trouble.
- A "no-bad-news" environment: Nobody likes to be the bearer of bad news, but sometimes organizations need to face the reality of negative news. This includes project team members who don't want to be the messenger and business leaders who tend to shoot the messenger. If there is not an environment where the communication is honest about "reality," projects tend to fail.
- Lots of overtime: A project running on schedule should have little or no overtime. Overtime is often a quick fix, but leads to poor employee health resulting from too much caffeine, too many late nights, and too much junk food. (It also leads to mistakes.)
- Diversion of resources: When people are pulled from one project to work on something else it could be a sign of trouble. If you've budgeted your human resources properly, a few hours here and there on a troubled project can quickly add up and cascade down, endangering healthy projects.
- Ratios trouble: Cost ratios and schedule ratios are financial metrics that allow business leaders to measure budgeted time and money verses money and time actually spent. Without metrics, all you have to rely on is the accuracy of the communication you receive from project teams.
- Milestones aren't met: This is pretty obvious, but it is surprising how many times this warning sign is ignored. Small, discrete, and often, are the guidelines for the milestones of a successful project.
- Scope changes: A common approach to shoring up a lagging project is to change the scope. Eliminating features or relaxing requirements is not uncommon, but if project teams are doing it because the project is in trouble, it's a huge warning sign of danger ahead.
How do you spot struggling projects early—when there's still time to take action?
Friday, April 9, 2010
Four Early Warning Signs of a Project in Trouble, by Ty Kiisel
Underground mining is a dangerous occupation. What's more, before the advent of sophisticated breathing apparatus, methane and carbon monoxide made it even more dangerous for the men working in the mines. In the early days of underground mining, because their metabolism was susceptible to methane and carbon monoxide poisoning, canaries played an important role in keeping miners safe.
- They provided an audible warning: Canaries typically sing most of the time—when they stopped singing, it was a warning sign that they were being overcome by the toxic gas
- They provided a visual warning: When they started to sway and fall from their perch, it was a signal that they were succumbing to the poison gas.
I think everyone would agree that missing deadlines or exceeding budgets is evidence that a project is probably in trouble. However, those symptoms are often recognized after it's too late to do anything about it. Anyone doing project based work knows how important it is to recognize a project in trouble before it's too late. Not too long ago, I came across this list of early warning signs that every project manager should be aware of:
- Direction from management is either missing or inconsistent: The only thing worse than project leadership that is missing in action, is direction that contradicts itself and changes frequently.
- Business management and project management aren't on the same page: If the project gets consistent direction, but it's at odds with company business objectives, there is more than likely a problem.
- Project goals are not clearly articulated and understood by the project team: Although every project usually has a business goal or two—projects without a business objective should probably be reconsidered, right?—often those goals aren't clearly articulated or understood by the project team. Occasionally, the business objective is thought to be so obvious it's never clearly stated. Unfortunately this could lead to misunderstanding and inconsistent presumptions about priorities.
- Team members don't communicate with each other: Sometimes, even teams that get along well don't communicate well. Communication and collaboration are essential to any successful project.
Monday, April 5, 2010
Tips to Increase Software Development Efficiency - by TLoop
It's important to care about what you do. If you don't then the end product will not showcase your best skills and/or abilities. The software will probably not perform as seamlessly as your would expect. If you feel like you are in a slump as a software developer then step back and re-assess your profession. Maybe you need to change focuses or try to learn something knew so you don't feel like you are performing the same tasks day-in and day-out.
Remember to provide options to your clients. If you are not sure how something can be done try to see if you can learn how to perform certain functions. Over time you will add a new skill set to your tool belt and help grow your knowledge base. Software development is always changing and staying on-top of these changes will only continue to help you.
Create contracts that help protect yourself. You want to make sure that you provide clients with software that meets the outlined expectations, no more and no less. Having a contract that is highly specialized and specific will help you keep your development within the scope of the project. If you don't have a project scope, you may be spending too much time of the project and limiting your revenue growth.
It's increasingly paramount to think about your work. Over time you will develop certain business practices, do these practices hinder your performance or make you more efficient? Outlining and reviewing how you conduct business and develop software is a great way to access factors that can help you with your job.
Take the time to access your performance and review ways that can help your increase your efficiency during the software development process. Overtime you will develop effective and efficient software development practices that help generate fully functioning and powerful software.
Wednesday, March 24, 2010
The Future of Project Management - Stacy A. Goff
Monday, March 15, 2010
The Case for Project Management - C. Wayne Peal
As all of those who have worked in the trenches well know, successful project management is the tie that binds services to results." So saidGovernment Executive in introducing a series of articles on successful federal projects in the July issue. But is the statement true? Do all in the trenches really know about project management? Do their leaders support and understand sound project management approaches? Are those approaches part of the culture of federal organizations? Is project management used appropriately - especially in guiding information technology projects?