Can I instal prolog on the Raspberry Pi

Yep.

sudo apt-get install swi-prolog

Is numpy included on the Raspberry Pi

Yes it is.
My Raspberry came with Raspbian Wheezy installed.

At the command line I started python,

then entered:

>>> from numpy import *
>>> a = arange(15).reshape(3, 5)
>>> a

 Which gave:

array([[ 0,  1,  2,  3,  4],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14]])
>>> 

How to select the Python.3 interpreter in Eclipse on a Mac

This foxed me for a bit.
I have Pydev installed, and Python 2.n and all is well. But I needed Python 3.3

Install 3.3

So go to Python: http://www.python.org/download/ and download the installer.

Then install as usual on a Mac.

Now check that it's in place.
There should be a folder in Applications/Python 3.3

There should also
Macintosh HD - Library/Frameworks/Python.framework/Versions/3.3

Select the interpreter.

So now, select the interpreter in Pydev.

1. You go to Eclipse > Preferences > PyDev > Interpreter - Python
2. From here you, Select New, 
3. in Interpreter Name you enter python3 and in Interpreter Executable you enter /usr/local/bin/python3 or /usr/local/Cellar/python3/3.3.0/Frameworks/Python.framework/Versions/3.3/bin/python3.3.
4.  OK

Lego Nxt plug connector for Raspberry Pi

I haven't done this yet but I'm getting ready to. That is, connect the Raspberry Pi to the Lego NXT Mindstorm sensors.


I've a circuit schematic, but there's also some good info on how to adapt a regular telephone plug to use a NXT socket.
http://www.philohome.com/nxtplug/nxtplug.htm

You'll need to cut and file a bit.

How to connect the socket on the Pi for a NXT cable.

I haven't actually tested this yet. Maybe next weekend :)
My advice would be to use this as a starting off point and experiment.

How and why to document Business rules (and Use cases)

Business rules are, I think, not given enough consideration in the projects I come up against. I'm a bit of an itinerant member of smallish teams and regularly see teams short on resource and time. Often I hear people speak of "business rules",  and nearly every project I've been on I've not seen anyone documents them.
Perhaps they don't need documenting. I think they do.

In my most recent contract one project had an incredible amount of Business rules. The task of the project was to replace an old system and set of accompanying processes with a new set. Most of the Business rules were to be in an "expert system" to do with qualifications, grades and occupations but there were many outside of that. The expert system was techie and geekie and obtuse but it documented the rules via the application's UI so they were taken care of, almost by accident. The rest were stumbled upon, discussed in emails by people who didn't know for sure, and either forgotten or if we were lucky, a code change was made to support it. Either way the rule was lost either in code or the fog of the project. And this continued for years.

The project team was under-strength and spread over three locations, business analysis was inexperienced and absent for some months, and the project was far more complex than anyone really expected. For my sins I came into the project after two years and immediately struggled. After my first eight months the first major phase was working. Which is ok I suppose. I'm only saying this as an example. It's an example in the general sense and to a lesser or greater degree it is common.

The general picture of the development and project process in this example would be to say that some of the developers wanted a Scrum approach but other developers distrusted this and management certainly distrusted this. So Scrum was replaced by a version of nothing in particular. This is pretty common too. So what could have happened at the beginning to have made it all smoother?
The objective for the process at the beginning of the project was to let the Business knew what they were letting themselves in for as the foundations of the project were being laid and details being discovered.
What is it that we are really going to be building?
What changes is this thing going to make to the business processes, to the people, to the productivity, to the service? Oh and how many people will be needed to get this all done and how long will we have to wait?

The way not to do this is to get inexperienced people to document the requirements and blame them a few years later if it goes titsup. What not to do after this is to get all excited and give it to the developers, stand back, and wait for the first delivery.

The Scrum thing will not work here. What we should do is think about the business processes. What is it that the Business is doing and how will we change that. There are ways to document this and be all professional (BPMN see bpmn.org). But if you are without a BA a quick google can help. Something is better than nothing. A flow chart, a list of processes in MS Word is a great way to frame the problem domain. The Business Domain.

But this post is about BusinessRules. So where do they come in?

For me they come in alongside the Use Cases, or User Stories. Quite often a User Case or Story can be a Business Rule. For example, A Business Rule could be that we send a summary of trades to the Ombudsman within 20 days. This could also be a Story, As Compliance Manager, I must send the summary of trades to the Ombudsman within 20 days of the request.

However, it may be slightly different. Perhaps the story / requirement will be for a configurable date or alerting system.

Also, Business rules may define the data being held on a customer, and when it must be deleted for data-protection regulation purposes.

For me, the huge benefit of use cases is the fact that they describle, in easy terms, how a lump of work is done. A process. A small process. That is the business and that is what out work is going to support. Starting with declarative technical requirements such a the "the Save button must confirm the user is saved in the database before saving the data." is so abstract and difficult to communicate to a non-technical business user in a project meeting. They must be good for the development team a bit later on, maybe in a work unit, a task detail, but not in a 100 page requirements document.

How to start with Business rules

I always create a document with a few sentences explaining why the document exists, and then I put a list of Business Rules, and then Use cases.

The only important rules I apply to the writing of business rules is:

The rule is not dependent on nor refers to any technology or system. The rule should be equally valid if the business was being run using a pencil and paper.

Rules should be grouped into easily understandable and relevant groups. And each Business Rule should have three fields:

1. An ID (can be a number or a letter and a number). The letter can relate to the title of the group of the rules. If  a rule is in a group entitled Refund Business Rules, then number the rules R1, R2, R3...
2. Business rule name, one to 4 words in length
3. A short description of the rule. 

Rules can be things like:

• what bits of data are mandatory, 
• what bits of data are to be removed.
• Trading days,
• Compliance issues.
• Regulatory points.
• Welfare issues
• ...