ExpressionLab - Home

Using Savage Beast, the Rails Forum Plugin

2010-08-27T08:46:00Z

Probably Beast is the most famous forum Rails app. One issue most developers have is adding a forum to an existing application, rather than starting from scratch. Savage Beast does exactly that. It is a Rails plugin based on the famous Beast. Here is how to add Savage Beast to your existing Rails app.

The only prerequisite is that your Rails app should have a User model. You can start with my Janrain Engage Demo.
Install required plugins:
1. Install savage-beast plugin:
```
script/plugin install http://github.com/valodzka/savage-beast.git
```
2. Move "white_list" and "white_list_formatted_content" plugins from \vendor\plugins\savage-beast\tested_plugins to \vendor\plugins

Install required gems:

# environment.rb
config.gem 'savage-beast', :lib => 'beast'
config.gem 'will_paginate', :version => '~> 2.3.14'
config.gem 'acts_as_list'
config.gem 'RedCloth'

rake gems:install

Generate the beast:
```
script/generate beast
```
```
rake db:migrate
```
Start the server:
```
script/server
```
Navigate to /forums and enjoy!

NOTE: If you get the following error: "A copy of ApplicationController has been removed from the module tree but is still active!", add the following to /config/environment.rb:

config.reload_plugins = true if Rails.env.development?

Customization

Implement login_required and current_user in your application controller
Implement display_name and admin? in user model
To override, create files in your /controllers or /views directories with the same name

Demo

I have create a demo app, Savage Beast Demo, for demonstration.

History of the Internet

2010-08-23T06:16:00Z

The internet is a fantastic invention that has changed the way we live. In honor of the internet, Jason Powers has designed the following infographic highlighting the major events in internet history.

Janrain Engage (formerly RPX) on Rails

2010-08-02T12:45:00Z

Janrain Engage (formerly RPX) allows your visitors to login to your website with their existing accounts on Facebook, Google, Twitter, Yahoo!, LinkedIn, Windows Live, MySpace, AOL or other networks and then gather their profile data and publish their activities from your website to multiple social networks. I have just committed Janrain Engage Demo, a simple Rails app that demonstrates the usage of the rpx_now gem to add Janrain Engage to your Rails app.

Features include:

Supports Rails 2.3.8
A user can login using a popup or embedded widget
User data (identifier, username, email) is extracted and the user is auto-saved if valid
A user with invalid data is redirected to fix the auto-filled data
current_user represents the currently logged in user
You can use before_filter :require_user to protect restricted actions
A user requesting a restricted action is redirected to a login page with an embedded widget
Once logged in, a user is redirected to the requested action

For more info, check it on GitHub: http://github.com/hatem/janrain-engage-demo

Task Cards: The First iPad App from eSpace is now in the App Store!

2010-07-27T03:32:00Z

eSpace just released version 1.0 of Task Cards, the easiest task management app for the iPad. It uses index cards to organize tasks on a desktop, and provides simple tools to manage them.

Features include:

Tasks can be shared across index cards
Due dates and recurring tasks
Priorities
Search
Notes
Sorting by due date, priority, or alphabetical
Quick access to overdue and today's tasks
Ability to see completed tasks on the back of a card

Network Security Applications

2010-06-21T09:17:00Z

Here are the slides I have presented yesterday on network security applications. It was a quick presentation with an example of an authentication application, Kerberos, and a web security standard, SSL/TLS.

Agile Roles and Responsibilities

2010-01-09T05:41:00Z

Managing and leading software projects, I have always seen debates on the different roles required and the responsibilities of each manager and team member. Traditional process models have a lot of isolated roles and agile models always argue about shared responsibilities and self organized teams.

Regardless of the size of the project and the number of team members, I found that managing a successful project always require three main roles to manage three main parts. It requires a product owner, a project manager, and a team leader to manage the product, the project, and the team, respectively.

Similar roles can be found in many traditional and agile models but with different responsibilities. You may find them under different names like facilitators, coaches, trackers, mentors, masters, etc.

Product Owner

The product owner works with the customer and ensures they get the highest business value possible. This can be the traditional business analyst and the agile customer.

Helps the customer to define the requirements and convert them to stories
Works with the customer to organize and prioritize stories in the product backlog
Provides initial estimates for stories and releases
Tracks customer requirements and changes (new features, bug reports, investigation requests, performance issues, etc.)
Sits with the Team Leader to discuss story details, business constraints, legal issues, etc.
Provides input on mockups and prototypes
Sits with the tester to set and track product quality
Sits with the Project Manager to review the previous release and plan the next
Manages customer relationship and ensures customer satisfaction

Project Manager

The project manager is responsible of the overall planning and tracking and ensures the work is delivered in scope, on time and within budget. This can be the traditional project manager and the agile tracker.

Sits with the Product Owner to gather all requirements/estimates and integrates everything into a workable plan
Works with the management and Product Owner to provide and secure resources (people, infrastructure, licenses, etc.)
Plans and tracks cost to ensure the work is within budget
Identifies risks and works with the management and Product Owner to resolve them
Manages and controls scope to ensure that only what was agreed to is being delivered
Continuous planning for changes in requirements, cost, schedule, etc.
Tracks and communicates project progress and plan changes to Product Owner and top management
Sits with the Product Owner to review the previous release and plan the next

Team Leader

The team leader manages the team and ensures they deliver the highest quality possible. This can be the traditional architect and the agile coach.

Communicates with the customer to discuss the details of the iteration and each story included
Communicates with the Product Owner to discuss requirement conflicts, business constraints, legal issues, etc.
Performs iteration planning, daily planning and assigns tasks to team members
Controls the development process (iteration meetings, deployments, testing, client communication, etc.)
Provides team leadership and coaching to set a good example to the team
Directs the day-to-day activities of the team members and ensures they follow the standard processes and procedures
Coaches and trains team members through planning games, pair programming and peer reviews
Ensures that tasks are being done with a high quality (design patterns, coding standards, test coverage, type of bugs, etc.)
Transfers knowledge and encourages knowledge sharing across the team
Ensures that the team spirit and morale is kept and improves members confidence
Tracks and communicates iteration progress and team performance
Communicates with the Project Manager to discuss the progress
Sits with the Product Owner to review the previous iteration and plan the next

Team Members

Team members focus on implementing user stories using the best techniques and practices. They investigate, analyze, estimate, design, code, document, deploy and test stories. Those can be senior/junior developers, interface designers, system administrators, testers, etc.

Conclusion

A successful software project requires a product owner, a project manager, and a team leader to work together with the customer and the team. Of course, some responsibilities can be moved from a role to another depending on the project type and individual skills, but this is not valid for everything.

For example, the project manager may act as the product owner with some extra efforts but if the project manager acts as the team leader, you may have problems with the project schedule or code quality. Similarly, if the team leader acts as the project owner, you may have problems with the code quality or customer relationship. And so on.

Software Architecture – Part 2: Software Quality (SE Radio)

2009-12-12T05:41:00Z

In episode 25 of Software Engineering Radio, Michael and Markus continue on the fundamentals of software architecture by discussing quality attributes of software architecture and how they relate to each other. Here is the summary.

Quality requirements of software architecture can be grouped in different categories:

a) Operational requirements (run-time characteristics)

1. Performance

Performance has 2 measures:

Latency: this describes the time the system needs to react on an external event. This is very important in real-time systems and is usually relevant to embedded systems.
Throughput: this describes how many events can be processed by the system per second. This is more relevant to transactions systems.

Performance depends on several factors like algorithms, memory, bandwidth and communication overhead. Also, performance is defined for specific use cases and well-defined system configuration.

2. Scalability

Scalability is the ability of a system to keep its performance, or degrade slightly, when the load increases. So when the load doubles on a scalable system, you should get the same performance by doubling the hardware resources. And when you keep the hardware the same, if the load doubles, you should only get half of performance. This is especially important for enterprise systems where the load is not always known and can't be expected.

3. Availability

Availability is the ability of a system to be up and running, with a specified level of quality, in a percentage of the time. This can be calculated by: uptime / (uptime + downtime). For example, a system that fails every hour and automatically reboots in a second has a high availability.

4. Reliability

Reliability describes how often failure occurs in the system. A failure can be missing a deadline in a real-time system, or having low throughput, etc.

5. Usability

Usability has 3 measures:

Learnabiliy: how long does it take for a user to learn how to use the system and how efficient can a user operate the system. For example, web interfaces are very easy to learn but not very efficient to use if you have to do a lot of work.
Memorability (re-learnabiliy): how much a user can remember to achieve a certain task.
Developmental time: how easy the API is to learn and how it protects the programmer from making mistakes.

6. Security

Authentication is about who can use the system. Authorization is about what an authenticated user can do, which parts they can access.
A secure system needs to encrypt data sent over a network, avoid buffer overflow, be safe against denial-of-service attacks, etc.
Security should be planned and can't be implemented after the fact.

b) Developmental requirements (structural attributes)

1. Maintenability

Maintenability is the ability to extend or change your system by refactoring, removing features, supporting new scenarios, different platforms, etc.

2. Portability

Portability is the ability to run the system on different platforms, operating systems, networks, etc. This is usually not trivial require code changes.

3. Reusability

Reusability is the ability to use parts or components of the system in different systems.

4. Integratability (modularizability)

Integratability is the ability to develop parts of the system separately to be integrated later on. This is important with big systems that can't be developed by one team or in one location.

5. Testability

Testability is the ability to demonstrate that your system does what it is supposed to do. This includes unit tests, module tests and integration tests. Testability is a property of the architecture and is usually used to measure the quality of it.

c) Business requirements

1. Time to market

When it is expected to deliver the system to the first customer.

2. Cost

This includes how many resources, developers, managers can be afforded by the customer, how much effort should be spent in testing, etc.

3. Rollout schedule

Does the system have to be full up and running with no bugs, or some bugs can be accepted. Sometimes, you launch the system with some bugs because the time to market is more important. No system is free of bugs but you need to know how critical they are.

Sometimes, business aspects are in conflict with technical aspects. So it is always recommended that technical leaders get involved in these business aspects to get better idea of business constraints and customer priorities. It is important to keep the development team informed by the these business aspects but not stressed.

Relationships between quality requirement

There is no ideal system and you often have to compromise. For example, you may have to reduce the maintenability to get a better performance. But you should discuss these aspects with the customer to know their priorities and make such decisions explicit from the beginning.

Also, you can't maintain all quality attributes in parallel and you often have to balance the forces and make some trade offs to resolve conflicts. Some typical conflicts are:

Performance vs Scalability: to achieve an optimal performance, you can fine tune the system to a very specific environment, but scalability would decrease.
Performance vs Maintainability: to achieve high maintainability, you can separate every functionality with its own interface, but performance would decrease.
Performance vs Portability: to achieve high portability, which is a special case of maintainability, you can use several layers which separation of concerns, but performance would decrease.
Performance vs Availability: to achieve high availability, you can use several check points, and persist several states so it is easy to resume and minimize the down time but this usually is too expensive and adds performance overhead. For example, using redundant resources like duplicating all information between 2 databases.
Security vs Usability: to achieve high security, you may require users to fill a lot of forms and go through several steps, which conflicts with usability. For example, the firewall of Microsoft Windows was not turned on by default before XP SP2 because they didn't want to bother users with a lot of questions and messages.

On the other hand, some quality attributes can support each other. For example, maintainability can help availability as maintainable systems are usually faster to fix.

Software Architecture – Part 1: Fundamentals (SE Radio)

2009-11-23T05:41:00Z

In episode 23 of the Software Engineering Radio, Alex, Michael and Markus talk about the fundamentals of software architecture. Here is the summary.

Introduction

Software architecture is the art and science of designing and building software. To create a system architecture, you need to know the requirements and functionalities that the system has to fulfill and the interaction and dependencies between those functionalities. The hard part in system architecture is usually to address the non-functional requirements.

Software architecture is different from software design. Architecture is at a top level that guides and shapes the overall system with design guidelines and principles that the design should adhere to. The design is one level below specifying individual classes, objects, variables, etc.

The design is at a level that is not critical to non-functional requirements so different designs can fulfill the same architecture. So, if something is needed to be done in a specific way to address a certain requirement, then it is a part of architecture.

Agile Architecture

Some may think that Agile development doesn't need software architects but, actually, any software system has it own structure, architecture and important design decisions. Agile teams don't have an architect as a role because the architecture is not explicitly planned but created while developing the system. Of course, they always have to follow some guidelines to be able to grow without refactoring the whole system.

The Role of a System Architect

Communicates with all stakeholders to ensure consistency and resolve any conflicts. This includes communication with project management regarding requirements, with developers to share design guidelines, and sometimes with customers if some requirements affect the architecture. They should be concerned about technical goals without getting into politics.
Ensures the consistency of the overall architecture by regularly reviewing the design implemented by developers.
Guides and coaches developers to take good design decisions.
Defines the basic building blocks and the vocabulary that is used to discuss the system.
Contributes their knowledge and technical skills.

It is also important to notice that:

The full software architecture has to be built incrementally but the number and severity of the changes should become less frequent, otherwise the initial architecture was wrong.
Big projects, distributed over several locations, typically have a group of architects with only one lead architect who takes final decisions. But there should be a continuous communication to ensure they are all aware of different parts of the system.
Not every good programmer can become a good architect, they need to have strong communication and social skills besides their technical skills.

Software in Space (SE Radio)

2009-10-28T05:41:00Z

In episode 100 of the Software Engineering Radio, Hans-Joachim Popp, CIO at DLR, talks about software in space. Here is the summary.

Introduction

Today, software plays a major role in the construction of spacecrafts. It started in 1964 but it took several years and several catastrophes to change minds about developing mission-critical software for such high-risk environment.

Reasons for space disasters are not only programming faults but also severe faults in the requirements engineering and the analysis of the whole system. Here are some examples:

1. Ariane 5

Ariane 5 crashed just because some missing casting; it was just an arithmetic overflow that had cost about 1 billion Euros. Only some lines of code could have rescued that. That crash was the major point where the German software developers in the spacecraft industry began to think differently about quality assurance in software development.

2. Mars Climate Orbiter

The climate orbiter had calculation errors and didn't go into a proper orbit but got crashed on the surface of Mars. This was only because the calculation units were mixed; one team calculated in yards and the others calculated in metrics. This would be no surprise if the teams would have been in different countries but there were both in US. It was due to missing testing environments.

To avoid such faults, we should check out hardware pieces and simulate them by software one by one, so we have a better test environment with the complete system in software and in hardware.

How to Avoid Problems

Popp talks about space software development in DLR:

1. Process

Some projects have different teams from different European countries with different languages and cultures. So we have to apply really strict methods of cooperation.
We pay a great attention to requirements engineering as most of the problems we had came from missing requirements.
Our software development process is the standard V Model with some more steps in between. After the Architecture Design phase, we have a Detailed Design phase where we do a very low level unit testing against the detailed design.
Missions launch before we reach the end of the development because it might take years to finalize software. So we start the mission as soon as we have the basic software in place. After launch, we continue to learn on the way and update even core units of the software.

Today, 30 years after launch, one of our crafts are still speaking to us. This couldn't be without severe changes in the coding. The language was all assembly and the memory was only 4k. It takes images and uses a tape recorder to store them on tapes.

2. Tools

We use specialized operating systems that have been used and tested for many years.
Most software is written in pure C but the system and the testing environment restrict the use of certain instructions.
We don't use code generation but we invest about half an hour for each line of code.
The ratio between application code and test code is 1 to 12.
For code verification, we use PolySpace.
For configuration management, we use ClearCase.
We use automatic code reviews and automatic testing.
Automated tools can only find a small set of errors but most of errors are still in the requirements level (semantic level). You still have to review the whole system and to have a test environment where you play the whole mission through to see what happens.

3. Practices

The most important thing is to establish the culture of being free to make faults, to find them and to talk about them. Many catastrophes occurred because this was missing; most of the errors were known, but the management just closed their eyes.
Such mission-critical systems need redundancy in software, like having software parts written in different languages that control each other.
We regularly review the code in teams where developers explain the code to others who are not involved, junior developers ask questions, etc. This is very expensive and time consuming but it leads to a very high quality.
We measure quality by tracking how many faults we made, errors we found, the reasons they occur.
Pure development is only 40% of our time, 25% are invested in management and system engineering and 35% are invested in the design and integration test.
We measured our productivity and found out that having this high level of quality we can produce only 0.6 lines of code per hour.

Summary

In such high-risk missions, you have to go quite conservatively in slow steps.
Every member in the team should feel they are free to make, report and discuss faults.
Project managers have to be open for any remarks from developers.
We spend a hundred million Euros every year for software development. It sounds too much but this saves money at the end.

Requirements Engineering (SE Radio)

2009-10-24T05:41:00Z

If you don't know, Software Engineering Radio is a series of podcasts that covers all topics of software engineering. It is a very useful resource for professional software developers. In episode 114, Christof Ebert talks about requirements engineering. Here is the summary.

Introduction

Christof has seen from a number of projects and also from surveys in the industry that software projects have many problems. The reasons are many faults but one thing which is seen repeatedly is that requirements engineering seems to be the number one technical topic where projects either succeed or fail.

Requirements always change and if this is not well addressed, projects run into time and budget constraints and may be with insufficient quality. Things can go wrong up to the level of customers finding that the product is not really what they needed. That is the key reason requirements engineering is a major challenge in today's software development.

So requirements engineering is about defining what the system should do, what the value of the product is. This product can be a release of a software, a tool, a big IT system, an embedded software system, etc.

However, there is a relation between the "what" and the "how". In order to find out what should be done in a project, you need to address how it should be done because only by understanding how you will address certain issues, you are better positioned to ask questions to customers to know what are their needs. Also, it is useless to come up with requirements that are not implementable because they are too complicated or just not feasible.

Typical Pitfalls

Requirements engineering is not so difficult if we addressed all the risks. These can be of three categories:

Wrong requirements

Like when you produce a nice product in a market that doesn't need it, or when a competitor has a key functionality which you don't have.
Missing requirements

This is usually a result of misunderstanding customers or ignoring different users of the system with different levels of skills. If you talk to the wrong people, you have missing requirements.
Changing requirements

As a rule, requirements change. And if you are not capable of addressing changes by quality control, configuration management, etc, this will kill any project because you can't see where the changes impact is.

Types of Requirements

There are three main types of requirements:

Market requirements

These are the requirements from the user perspective. This is the problem space; what they think the system should do.
Product requirements

Usually called the feature set, these are how the product is addressing those market requirements. This is the solution space; what the product can offer.
Component requirements

This is how the product requirements can be translated into product functionality.

Also, you should differentiate two types of requirements:

Functional requirements

These are the basic functions of the system.
Non-functional requirements

Examples include how fast the product should process a file, how secure is it, etc.

Activities

The word "engineering" implies that there is a systematic approach to dealing with requirements. This includes a set of activities:

Elicitation

This gives you the "What". This is not just collecting requirements, it includes:
- Defining dependencies
- Understanding the customer's real needs. Normally you don't fully understand the business model, context, usage models, market, etc. Make sure you understand customer needs. Put your self in the position of the standard user.
- Knowing who to ask and considering different users. For example, managers usually care about time frame and economic requirements instead of functionality. Prepare a few questions that help you find out if they are you the right person to ask about a certain feature.
- Don't spend too much effort trying to expect all possible potential requirements before the project starts. Remember, requirements change.
- The outcome is:
  1. A concise vision on what value is to deliver
  2. A list of needs
  3. A draft requirements specifications
Specifications

This is about clearly describing requirements. The target is to get mutual understanding of what should be done and how it should be done.
- You need to get something on paper to reference functionality; like use cases
- Outcome: a written baseline about the requirements
- How to write specs that are not easy to misunderstand:
  - Specs are not a purpose in itself
  - Writing a glossary or dictionary to make sure you and your client understand each other
  - Using diagrams with description
  - Be precise. Don't use words like: might, perhaps, at least, etc. This makes it difficult to implement. Use numbers where possible.
  - Use modeling to have better understanding. Use UML or even plain text.
Analysis

This builds the bridge between the what and the how.
- Helps to address the write questions
- Helps you decide what kind of components, language, architecture, etc to use. So helps reduce the solution space
- Help you realize what constraints, priorities are there
- Helps you identify what are most effective requirements in terms of functionality and cost
- Prioritization analysis results in dependency graph. You would know if you remove a feature what market requirement will be missed
Validation

This about making sure you have addressed the right topics and understood what is needed to relate the product to customer/market needs.
- It builds a basis for test cases
- Good requirements should be achievable (technical and budget), testable, and implementable
Commitment

Now, we know customer needs, we know the way we want to address these needs.
- You need to map them into releases with time constraints
- Commit internally and externally: capacity and needs
- Don't commit too early until you are certain about all requirements
- Commit only to a subset of the requirements in initial iterations and once you learn more in the subsequent iterations, you can commit to more
- Make sure the parts that are not clear yet have no architectural impact. You need to know the nonfunctional requirements very early. But don't keep the analysis phase too long
Management

Requirements change and you need to manage these changes. This is actually the bridge to the development process.
- Make sure you always have a clear baseline
- When there is a change, trace it to the downstream and upstream requirements to know the side impacts
- Use modeling tools to build and maintain models
- Make sure u always have one main baseline
- This gives you Visibility:
  - Customer requirements and products requirements
  - Tracking changes; amount, impact, capability to handle. This can be used later to review
  - Status info about to which degree have you implemented a certain requirement, to which degree can you relate that to project progress. This helps you detect problems early.

Summary

Requirements engineering needs discipline
Requirements engineering is team work
Requirements engineering is about risk management
Requirements engineering is not linked to a certain development process
Requirements engineering is a part of the project that consumes resources but helps you handle changes, keep deadlines and deliver high quality products
Requirements engineering is not about formalism or unnecessary overheads

I hope you find this useful.

Please Vote for My Presentation on SlideShare

2009-08-28T05:41:00Z

SlideShare is the best way to share your presentations with the world. Currently, they are hosting their World’s Best Presentation Contest 2009. I have submitted my presentation, Web 3.0, The Semantic Web, which I have presented before at ITW 2009.

Please do me a favor. Check out the presentation and, if you like it, vote for it.

Web 3.0 The Semantic Web

2009-07-14T04:41:00Z

Here are the slides I have presented at ITW 2009, organized by IEEE AlexSB in Bibliotheca Alexandrina. The session was about Web 3.0, The Semantic Web.

Trying Kubuntu/Linux for Windows Users

2009-05-27T04:42:00Z

If you are a Windows user and just want to give Linux a try, Ubuntu is the right choice. Ubuntu is known to be "Linux for human beings" - the word "ubuntu" means "humanity" in the Bemba language. However, what usually keeps Windows users from trying Linux is the need for formatting a special partition and the complex installation steps that may damage Windows files.

A great solution to this is Wubi, a free Windows installer that allows you to install and uninstall Ubuntu as any other Windows application without the need for a dedicated partition.

Before we start, I want to mention that there are several operating systems derived from Ubuntu, Ubuntu derivatives. We will go with Kubuntu that uses a more user-friendly desktop environment, KDE, than GNOME that comes with Ubuntu.

So how to start? First, go download the latest version of Wubi, 9.04. Then, download the latest version of Kubuntu, 9.04, and place the .iso file in the same folder as wubi.exe. This way, Wubi will install Kubuntu from this .iso file. Otherwise, Wubi will try to download the latest version for you.

Now, run wubi.exe and:

Select the installation drive. This should be an NTFS drive with a minimum free space of 5 GB. I recommend 10 GB or more
Specify installation size. This is the maximum size of the file that will hold your Kubuntu. Note that you won't be able to change this size later unless you decide to migrate the installation to a dedicated partition with a different size. I learned this the hard way
Select Kununtu as your desktop environment
Enter a username and a password for your account
Press "Install"
After the installation is complete, press "Finish" to reboot the system

You should now see a new screen with an option to boot with Kubuntu. Congratulations!

Once you log in to Kubuntu, you will find two widgets, similar to Windows gadgets, on the desktop: Application Launcher and Home Folder. Using the icon on the top right corner of the desktop, you can add new widgets to the desktop or the bottom panel (similar to Windows task bar). To access the Terminal, use the "Applications" tab on the "Application Launcher".

The next thing you may want to do is to install Microsoft core fonts. Type the following in your terminal:

apt-get install ttf-mscorefonts-installer

Another thing to mention is that you may search for the "Show Desktop" icon on the bottom panel as you would do with Windows task bar. Unfortunately, you won't find it their. To add it, click the icon at the rightmost of the bottom panel, click "Add Widgets...", select the "Show Desktop" widget, press "Add Widget", and press "Close".

But what if you want to use the same shortcut you use to show Windows desktop? Right-click the "Show Desktop" icon on the bottom panel, select "Show Desktop Settings", press the big button to enter a keyboard shortcut, press both "Windows Key" and "D", and press "OK".

Finally, to uninstall Kubuntu at any time, use the Windows control panel as you would do with any Windows application.

Introduction to Symbian OS

2009-05-12T04:42:00Z

Here is the slides I have presented on Symbian OS in a course of my Computer Science diploma at AAST. The target was to present a session in 10 minutes!

Installing Mephisto 0.8.2 on Rails 2.2.2

2009-04-23T05:42:00Z

After the hard times with Mephisto, finally, Mephisto 0.8.2 has been released. Although all of previous problems were gone, there might be couple of tricks.

Again, following the link on the announcement post leads to a version that produces some errors while installing. After a while, I decided to give the master branch a try and, surprise, it worked just fine. Here are the steps that worked on Windows and Ubunto (the order is important):

If you didn't already, install Rails 2.2.2:
```
gem install -v 2.2.2 rails
```

Download from github:

git clone git://github.com/emk/mephisto.git

```
cd mephisto
```
Create a secret key for encrypting session cookies:
```
rake config/initializers/session_store.rb
```
Copy config/database.example.yml to config/database.yml and edit the database configuration
Install required gems:
```
rake gems:install
```
Create a database for the current environment:
```
rake db:create
```
Bootstrap the database with basic data and theme:
```
rake db:bootstrap
```
Start the server:
```
ruby script/server
```
Visit http://localhost:3000 and everything should be fine

By the way, if want to run the tests

rake db:create RAILS_ENV=test

you may get this error:

rake aborted!
Unknown database

To solve this, you need to temporarily disable class caching during database creation:

#config/environments/test.rb
config.cache_classes = false

Now, you should be able to run tests:

rake test

ExpressionLab - Home

Using Savage Beast, the Rails Forum Plugin

Customization

Demo

History of the Internet

Janrain Engage (formerly RPX) on Rails

Task Cards: The First iPad App from eSpace is now in the App Store!

Network Security Applications

Agile Roles and Responsibilities

Product Owner

Project Manager

Team Leader

Team Members

Conclusion

Software Architecture – Part 2: Software Quality (SE Radio)

a) Operational requirements (run-time characteristics)

1. Performance

2. Scalability

3. Availability

4. Reliability

5. Usability

6. Security

b) Developmental requirements (structural attributes)

1. Maintenability

2. Portability

3. Reusability

4. Integratability (modularizability)

5. Testability

c) Business requirements

1. Time to market

2. Cost

3. Rollout schedule

Relationships between quality requirement

Software Architecture – Part 1: Fundamentals (SE Radio)

Introduction

Agile Architecture

The Role of a System Architect

Software in Space (SE Radio)

Introduction

1. Ariane 5

2. Mars Climate Orbiter

How to Avoid Problems

1. Process

2. Tools

3. Practices

Summary

Requirements Engineering (SE Radio)

Introduction

Typical Pitfalls

Wrong requirements

Missing requirements

Changing requirements

Types of Requirements

Market requirements

Product requirements

Component requirements

Functional requirements

Non-functional requirements

Activities

Elicitation

Specifications

Analysis

Validation

Commitment

Management

Summary

Please Vote for My Presentation on SlideShare

Web 3.0 The Semantic Web

Trying Kubuntu/Linux for Windows Users

Introduction to Symbian OS

Installing Mephisto 0.8.2 on Rails 2.2.2