|
Written by Daniel Leiderman-Gueller
|
|
Sunday, 14 June 2009 00:56 |
In previous posts, I've discussed the use of a wiki for information sharing in an intranet. The main idea is having a central repository where each user can provide its insight and discuss the presented information. The posts discussed the requirements and possible alternatives.
The finalists were:
First TikiWiki was tried, as it was heavily recommended for CMS and wiki. The installation was a breeze, because a Linux server was available for testing with the required prerequisites already installed.
During the testing some things became clearer.
- The wiki needs to support well Microsoft word documents, for importing and exporting.
- Wiki management is a difficult task, specially for configuring the first settings.
- Selling the idea of a wiki is way easier than making others use it. The wiki should be designed to solve real problems and have a compelling reason to be used.
After having the insights, the whole strategy changed. The software options were limited to software supporting easy import and export of Microsoft documents. At the same time, I'm looking for people that are willing to give the wiki a try and create content with it.
The wiki software I'm going to try is:
My hope is people finding the wiki as helpful as I think it can be and easy to use so it can help everybody. After using xwiki I'll update on next steps.
|
|
Last Updated on Thursday, 18 June 2009 11:29 |
|
|
Written by Daniel Leiderman-Gueller
|
|
Thursday, 04 June 2009 10:41 |
|
The kindergarten information site has specific requirements, same as any other project. Normally the requirements are specified in some requirement document or RFP. Unfortunately, for this kind of project I have to make the requirements and analyze the consequences.
The requirements can be divided in 3 categories:
- Functionality requirements - what is the site required to do.
- Non functional requirements, also known and quality attributes - how well then site is required to be.
- Security functionality - the security model and information management within the site.
Since no end users are available, the requirements are specified here:
- functionality requirements:
- the website should allow presenting information regarding activities of each child, joint and separated.
- Information is one of several categories and includes comments.
- The information should be entered in a table, as easily as possible
- non functional requirements:
- support up to 20 parents and children
- support any browser and operating system
- support customization of the website css and users
- can be deployed in secure environment
- suitable for hosting
- fast development time
- security requirements
- segmentation of information between parents and staff
- support of authentication and anti spoofing
- use safe password storage mechanism
These are some really basic requirements allowing for analysis and initial decisions to be taken.
Operating system, language and database is a no brainer, as I support Linux and open source, so its LAMP: Linux, Apache, Mysql and PHP.
Regarding the 4 questions for a basic project:
What: web site for information sharing between kindergarten and parents:
How: develop a website software using PHP in LAMP configuration.
How much: one site, supporting up to 20 children.
When: Start now and actual use by end of August.
As you can see, even with very sketchy requirements, some basic design and architectural decisions can be taken.
|
|
Last Updated on Thursday, 04 June 2009 10:58 |
|
Written by Daniel Leiderman-Gueller
|
|
Sunday, 31 May 2009 01:09 |
|
Open source is all about sharing, giving and receiving; an open exchange of ideas, code and effort. The funnel of this effort exchange is the maintainer, the one who receives the code and incorporates it into the codebase. But sometimes the perfect world of open source is influenced by commercial initiative and conflicts arise.
Let's assume an open source project with a commercial sibling. The commercial sibling is differentiated with additional features, not present in the open source version. In this scenario the maintainer has a conflict of interests due to having two incompatible hats. One hat is being the open source maintainer, keeping a healthy community, motivating developers and presenting a future goal for the product. The other hat is the responsibility for maintaining the differentiation between the open source and the commercial version.
There are examples of this conflict in various open source projects:
What would happen if a contributor would code a feature similar to the one present in the commercial version? It can be rejected, for some obscure reason, and the status quo kept. In the long run, the open source version will be less capable than competitors and the community will react with a branch. See foswiki vs twiki.It can be accepted and the bar between the open source and commercial grows, so the commercial part needs to invest effort to make the product worth the price difference.
Since open source is about sharing, having commercial barriers is almost an anti thesis. But with the right combination of offering (support, training, etc) and the right mix of features, the conflict can be kept to a minimum for the benefit of open source projects. |
|
Written by Daniel Leiderman-Gueller
|
|
Tuesday, 26 May 2009 05:38 |
|
Sometimes a new idea can just be the thing you need, to motivate you in an interesting direction.
Discussing information management with my wife, it became apparent that a kindergarten might benefit from having a site to communicate with the parents. The site would be for allowing the parents receive information on the well being of the children, statistics, and activity summaries.
Since this idea is quite interesting as business proposition I've started to analyze what is the development effort is it viable for me to do it. There are several learning curves to follow: learning new languages (HTML, CSS and PHP), development environment & deployment environment.
As it has been a long time since I coded actual code, I'm going to do it publicly, presenting my thought process. The goals for the project are quite simple:
- Have a working application
- Have a case study for system design analysis
- Have a place to describe the process, from initiation to finish
- Have a place to rant about development
- have a showcase for the site
The development process will be slow because I do it on my free time.
I'll try to make it a weekly post on the development, while another post will be dedicated to other subjects as I feel motivated to write. |
|
Last Updated on Friday, 29 May 2009 14:38 |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 5 of 19 |
