Monday, August 10, 2009

how to recover mysql server root password?

If you have lost your mysql password for some "ding dong" reason, :P

here is how to recover them:
1. stop the mysqld service by: sudo /etc/init.d/mysqld stop
2. start: mysqld_safe --skip-grant-tables &
3. login without pwd: mysql -u root
mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit
4. stop mysql: sudo /etc/init.d/mysqld stop
5. start mysqld: sudo /etc/init.d/mysqld start
6. try login via: mysql -u root -p (with yournew pwd)

Wednesday, August 5, 2009

Change Request

Its usual that under many circumstances, customer / client will change their mind or change their decision in tuning their software towards their objective.
Every change requirement shall have a "change request" document signed by customer/client.

A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process.

SRS

Every project shall have a well written requirement. One of the best requirement document design will be SRS.

Software Requirements Specifications (SRS)

Cover Page

Revisions Page

Table of Contents

1 INTRODUCTION

1.1 Product Overview
1.2 Purpose
1.3 Scope
1.4 Reference
1.5 Definition And Abbreviation

2 SPECIFIC REQUIREMENTS

2.1 External Interface Requirements
2.1.1 User Interfaces
2.1.2 Hardware Interfaces
2.1.3 Software Interfaces
2.1.4 Communications Protocols
2.1.5 Memory Constraints
2.1.6 Operation
2.1.7 Product function
2.1.8 Assumption and Dependency
2.2 Software Product Features
2.3 Software System Attributes
2.3.1 Reliability
2.3.2 Availability
2.3.3 Security
2.3.4 Maintainability
2.3.5 Portability
2.3.6 Performance
2.4 Database Requirements

3 ADDITIONAL MATERIALS


Reference:

http://en.wikipedia.org/wiki/Software_Requirements_Specification

Tuesday, June 23, 2009

wikimedia setup

Wiki media configuration tips:

Edit LocalSetting.php

How to setup only logged in user can edit / add post:

//only logged in user can edit
$wgGroupPermissions['*']['edit'] = false;
How to setup only admin can add user:
//only admin can create account...
$wgGroupPermissions['*']['createaccount'] = false;
How to enable upload for wiki media?
//find for $wgEnableUploads
$wgEnableUploads = true;
How to allow upload of other files:

$wgFileExtensions[] = "zip";
$wgFileExtensions[] = "gz";
$wgFileExtensions[] = "pdf";
$wgFileExtensions[] = "doc";
$wgFileExtensions[] = "xls";
$wgFileExtensions[] = "ppt";

But, upload will fail if you enable imagemagick, because it assume all your is image. Therefor, we will need to disable imagemagick:

$wgUseImageMagick = false;

Hope it helps ;)

Reference:
http://www.mediawiki.org/wiki/Configuring_file_uploads#Upload_permissions

Monday, June 22, 2009

drupal vs wordpress vs joomla

My findings:

Drupal:
Good:
  • very modular
  • able to reuse other module
  • allow theming overrides
  • drag n drop ordering of fields
  • allow custom fields
  • front end & back end having similar login and path
  • good interface
  • inserting folder as module make things simple
  • cutting edge - using tinymce3...
Bad:
  • Complicated admin
  • Slow admin interface as 2 much form input in 1 screen

Wordpress:
Good:
  • allow theming overrides
  • drag n drop ordering of fields
  • allow custom fields
  • nicest gui and friendliness among 3 cms
  • cutting edge technology - using wikimedia, tinymce3...
Bad:
  • TODO

Joomla:
Good:
  • Clearly separate module, controller & view
  • allow theming overrides
  • support hooks

Bad:
  • no custom field support
  • admin no hook support, therefore hacking core is unavoidable
  • some bad component design like jevents use their own templating, which is bad
  • inconsistant template - esp. between category & section
  • interface is like erp, not so good...
  • difficult to reuse other module functions
  • mootool 1.1 & tinymce2 legacy stuff!
  • component/module/plugin installation is tedious, need to pack and clear db if something went wrong

Tuesday, November 25, 2008

Working Modal for Development

Most developer / software house does not put time to organise their concept of development.
Especially in Malaysia, most companies try their best to tender for project which squeeze their time and budget to as minimal as possible, leading to untested and non-flexible (rapid) system.

One of the best modal to work on will be:
AMDD - Agile-Modal Driven Development

It uses modal concept to plan overview system flexibility, while implementing TDD (Test-Driven Development) to have system test unit developed before the actual development begin.
By using this concept, development can be planned from overview to tasks to-do, and allow brain storm on variety of posibilities of business processes.

Project estimation has to be planned with a range of posibilities, problem from: simple case scenario to worst case scenario (everything that could involve, and more...) .

Each client have to understand that development of software requires proper planning.
Any changes on the system could involve major changes. For example, we can refer to any building structure. We can do changes on or in the building itself, but not changing the overall structure of the base nor the pillar concept. Changes on the overall structure could lead to reconstruction of the entire project, which could lead to duplication of afford and time used.

As a professional, we who is in the software development industry should see things in a long run. We should set a border line for time and money, in order to ensure everyone have a fair treatment and time constraint. For example: standardization of petrol price. If each petrol supplier tend to fight for lowest price, quality of product will reduce. People will tend to find the cheapest cost to deliver the software.

Comparing TDD and AMDD:

  • TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.

  • TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.

  • TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.

  • TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.

  • TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.

  • TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).

  • TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.

  • TDD is non-visually oriented whereas AMDD is visually oriented.

  • Both techniques are new to traditional developers and therefore may be threatening to them.

  • Both techniques support evolutionary development.


Reference:
http://www.agiledata.org/essays/tdd.html

Please correct us if we did any mistake on the article above.
Feel free to drop us comment :)