The responsibility of a project’s outcome is shared between developers and managers. Developers depend on managers to effectively manage projects, and managers depend on developers to provide reports that serve as the basis of project management decisions.
Possibly due to insufficient transparency, a problem may be detected after attempting to use a fully implemented and unit-tested software component. The integration phase of a software life cycle is a common, but undesirable, phase to detect interface issues. The problem, found during the integration phase, potentially reopens tasks that were considered complete. Design documentation might need to be updated, software might need to be re-implemented, and software might need to be retested. This increases the difficulty of meeting a project schedule, which may already be tested during integration.
The person that detects the problem has the responsibility to make the problem known. Resolving the issue among developers of the affected modules may be possible, but in general, resolution will involve too many people and too many tasks. Utilizing the managerial structure is pragmatic and effective in coordinating a resolution. A line manager or immediate supervisor is an entry point of using the managerial structure, so reporting the problem to that manager is reasonable.
Without a problem report, management is unaware of the problem and unable to manage the project with respect to the problem. Reporting the problem to management is a practice that increases project visibility. Management may decide that the problem shall not be resolved, because of schedule pressure or the severity of the problem. Management may decide that it shall be resolved within the constraints of the project schedule. Management may also decide to resolve the issue and revise the project schedule. Management must make the decision for the project, but the need for a decision must be made visible by developers through problem reports.
I have just completed transitioning to a new server, which serves this blog. I am now using GoDaddy.com’s Virtual Dedicated Server product. I have been administering my own dedicated server, GoDaddy.com’s Dedicated Server product, for more than two years. I changed from a Dedicated Server to a Virtual Dedicated Server to reduce costs and better fit my utilization.
Though, I am not sure when the last time I rebooted my old dedicated server, the result of running ‘uptime’ on my old server is:
XX:XX:XX up 790 days, 15:23, X users, load average: X.XX, X.XX, X.XX
As I publish this post, the ‘uptime’ on my new server is:
XX:XX:XX up 2 days, 19:52, X users, load average: X.XX, X.XX, X.XX
I am still searching for tools that would allow me to do web development with Python. I was leaning toward Zope, but it looks like I will be going a different direction with WSGI. WSGI seems very lightweight or minimalist, which requires me to research template engines. Kubica’s HOWTO Use Python in the Web refers to Mako, Genshi, and Jinja. Mako looks like a good candidate.
When thinking about software modules as service providers and consumers, from time to time, a situation occurs where a service provider and a consumer communicate through a common or shared buffer. In the sockets API, the consumer of a service provides the buffers from which write() sends and to which recv() receives. This can be made to seem sensible, since these I/O functions can be seen as operating on arbitrary buffers. In this case, the buffers can be viewed as owned by or being more associated to the service consumers.
There are other situations where certain buffers are used only when communicating with specific service providers. When many such service providers with their associated buffers are present in a system, it is very possible that the buffers will be placed within a “buffers module,” or a module that consists entirely of buffers. This effectively disassociates the buffers from their respective service providers. Identifying the correct buffer that is dedicated to methods of a service providing module is more difficult, if that buffer is defined as part of another module as opposed to being defined within the module that is providing the service.
An increased risk of duplicate code is realized when buffers are placed in modules other than that of the consumers and providers. Implementers of service consumers may feel the need to independently implement functions to operate on these buffers. The duplication of code may be due to the lack of communication and coordination between the implementers, but this confusion could be minimized by recognizing the logical cohesion between the buffer and service provider, and placing the buffer within the module that outputs its results through said buffer. The service provider is also expected to implement functions that operate on its buffer. This localizes the functions that operate on the buffer to the service providing module, thereby reducing the risk of duplicate code among consumer modules with regard to the buffer and increasing cohesion between the buffer and the service providing module.
I was thinking about doing web application development using Python during my free time. It would not be something that is pressured by schedules, but it would be an opportunity to learn something new.
At first, I believed that most Python web applications were implemented by using mod_python, since PHP web applications use mod_php. I have read about mod_python and tinkered with it a couple of years ago. From what I remembered, mod_python was very low-level. A quick search on the Internet about Python web application development gave me Python for Web Development in Apache.
I looked at the API documentation for Pylons, Django, and Zope. It looks like I may be going with Zope. I have begun this endeavor with The Zope Book.