Design to last
Making career decisions Print E-mail
Written by Daniel Leiderman-Gueller   
Wednesday, 24 June 2009 13:08
This is a post by a software engineer trying to make a career decision.Career decisions
The question can be summarized as: "do I need to take this path or the other one?".  These career decision questions are normally phrased as stumbling upon an opportunity, encountering a dead end or you simply feeling the need to make a change. I have a problem answering the questions, as the questions only show one aspect of the dilemma.


The questions show the dilemma as choosing a path and looking the direction this path takes you, expecting a clear view of the outcome. The rational is to select the best outcome and see the decision as a critical point in time. My perspective is different, there is a process and a change evolved in making career decisions.


The process of career buildup requires dedication, perseverance and constant adaptation to change.  There are no shortcuts to building competence, as detailed in the post on learning in 10 years. There is an amount of experience you need to accumulate and some errors to be done. Then the question regarding career paths becomes a question of experience given and taken in the specific role.  Why giving? Because making errors is a way of giving to the company, making the errors an opportunity and in turn making the question not about choosing but about attitude and actions while doing the job.


My answer to the question presented in the beginning is actually a new proposition: "where do you think you will make most errors, and where would you be accumulating the experience in doing something?"



Last Updated on Thursday, 25 June 2009 05:46
 
Pet project - what In What time Print E-mail
Written by Daniel Leiderman-Gueller   
Tuesday, 16 June 2009 12:33


Timeline:

  1. Start of project - June 1st 2009.
  2. Deployment - Sept 1st 2009.


Actual available time: 3 months - 12 weeks.

Since a week is a easy to manage time frame, the work is divided into specific work items:


Item

Content

Duration

(weeks)

User perspective design

Information

Flow

User actions

1

Backend logic

DB design

Flow design

Information model

2

URL logic

Pages flow

relationships

0.5

Infrastructure coding

DB coding

DB interface coding


1

Main page coding

Menus

Links


2

Table presentation coding

Presentation table

Editing table

2

Security

Logic

Cookies

Enforcement

2

Testing

Developer testing

End user testing

4

Total


14.5



Due to the limited timeframe, only a subset of the application can be developed, forcing stepped development. For stepped development, grouping functionality allows concentrating on specific features without having to skimp all over the place.


As first step of the project, only three features need to be developed:

  1. database
  2. Menus and URLs
  3. main table display



Having these 3 features allow internal deployment, using a local computer and the parents reading the information from a monitor.


So the plan now is:


Item

Content

Duration

Design

Data model

Urls

Site flow

2 weeks

Database

Table creation

SQL queries creation

1 week

Main Page

Header

Footer

Menus

Links (static)

2 weeks

Main table

Calendar

Main entry table

Main display table

2 weeks

Testing

With sample or real data

2 weeks

Total


9 weeks


Having 14 weeks, this is doable, even with some delays added.


Now comes the hard part, actually making it.




Last Updated on Thursday, 18 June 2009 11:23
 
wiki update Print E-mail
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:

  • twiki
  • tikiwiki
  • mediawiki


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.

  1. The wiki needs to support well Microsoft word documents, for importing and exporting.
  2. Wiki management is a difficult task, specially for configuring the first settings.
  3. 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:

  • Confluence
  • Xwiki


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
 
Pet Project - Basic analysis Print E-mail
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:

  1. Functionality requirements - what is the site required to do.
  2. Non functional requirements, also known and quality attributes - how well then site is required to be.
  3. Security functionality - the security model and information management within the site.


Since no end users are available, the requirements are specified here:

  1. functionality requirements:
    1. the website should allow presenting information regarding activities of each child, joint and separated.
    2. Information is one of several categories and includes comments.
    3. The information should be entered in a table, as easily as possible
  2. non functional requirements:
    1. support up to 20 parents and children
    2. support any browser and operating system
    3. support customization of the website css and users
    4. can be deployed in secure environment
    5. suitable for hosting
    6. fast development time
  3. security requirements
    1. segmentation of information between parents and staff
    2. support of authentication and anti spoofing
    3. use safe password storage mechanism

Design is like playing


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
 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 1 of 16