Skip to content

Author: admin

Published on
pfSense firewall
Hardware firewall

We have seen at the "How to assemble a low cost firewall with professional capabilities" article how to construct our cheap firewall.

It is now the time to install our software firewall on our hardware device.
The first step is to find the right pfSense version from the dedicated web site.

Take a look at the versions page to find out which version fits at your needs.
1)pfSense-2.X.X-RELEASE-arch.iso.gz  --> Live CD/Full installer 
2)pfSense-memstick-2.X.X-RELEASE-arch.img.gz --> USB stick installer 
3)pfSense-2.0.1-RELEASE-size-arch-nanobsd.img.gz --> NanoBSD/embedded (Serial Console) 
4)pfSense-2.0.1-RELEASE-size-arch-nanobsd_vga.img.gz --> NanoBSD/embedded (VGA Console) 

In our case we will focus in the NanoBSD version embedded serial console.
From pfSense we see that the "embedded version is specifically tailored for use with any hardware using Compact Flash rather than a hard drive.
 CF cards can only handle a limited number of writes, so the embedded version runs read only from CF, with read/write file systems as RAM disks".

...continue reading "pfSense installation to a CF Card"

Pages: Page 1, Page 2

Published on
Inheritance-Abstract-GUI
Inheritance Abstract - GUI

Third and last step on the inheritance: here to describe a situation where this mechanism is required, or better forced, to be adopted, in case we need to create object from a class.

What precisely does it mean?
We always have designed and realized classes with the clear intention to be used as direct prototypes for instantiation of objects.

And that's right; but if you remember we, by talking about inheritance in the two last articles, mentioned that when a method in a class is declared as virtual, it means that every child of the class can override that method, but never it will be forced to do.

Let's face the other side of the medal: how to make necessary a redeclaration by every child of a particular class?
But before the practice, what is the idea guiding us?

Try to think of a general class, so general that it cannot be directly turned into reality: no need to concentrate on informatics applications, the physical reality of every day can help us.

...continue reading "Inheritance. The abstract classes"

Pages: Page 1, Page 2, Page 3, Page 4, Page 5, Page 6

Published on
Inheritance2-GUI
Inheritance 2 - GUI

By approaching with the concept and mechanism of inheritance it is possible to notice how it guides us from more generic classes into specialized ones, based on the project's specifics.

Inheritance is potentially infinite; only our needs (and computer's memory) can put a stop to the chain of children.
In any case what we learned is that the public and private attributes are inherited as they are: respectively public and private.
[But while the former are accessible, the latter aren't!]

The other aspect we talked about relates to necessity of specializing the new classes with new attributes and/or methods: a special setting wants a method to be shared among the father and the children classes, so that it can be declared virtual in the first.
It's required when a method, enough for the father which is initially designed for, becomes a base for the children where to be redeclared.
In the last article we saw the printing method, for the employees and the workers: a two-levels hierarchy, the simplest case of inheritance.

And if you remember (but you read it first? :)) we avoided to add a button, onto the form, bound to the redeclared method in the Worker class, because it would have been redundant; in facts it would have been same as using the direct Worker's printing method.

...continue reading "Inheritance. The protected attributes"

Pages: Page 1, Page 2, Page 3, Page 4, Page 5

Published on
Inheritance1-GUI
Inheritance 1 - GUI

The principle of inheritance involves the encapsulation mechanism too; so that we must pay attention to its usage.

In facts when we design a class and decide which items must be public or not, we bind them to precise ranges of action.

But now we add another degree in decision, because of the hypothetical necessity to design a class which at least to derive another one from.
This means that the inheriting classes receive all the parent's features exactly as they're written: private stuff to private, public stuff to public.

A last choice exists, under the protected zone (see in any class code we publish); but we'll see it next time.

But... why to inherit a class?

Certainly not to have just a copy, because it would be useless.

Surely to specialize the original class, called father, into a new one, called child.

A common example is the human being, which can become man and woman, for example.

...continue reading "Inheritance. A first insight"

Pages: Page 1, Page 2, Page 3, Page 4, Page 5

Published on
Aggregation-GUI
Aggregation GUI

By discovering the beauty of OOP world, in the essential view here offered, we always have underlined how the classes are designed as objects prototypes which implicitly include the possibility to communicate among them, with precise mechanisms.

For the sake of precision, some classes can be written only as general model, without the goal to be transposed in reality as objects.
While this is true, for now let's concentrate only on the fact that a class implies an instantiation, at least.

So the class design at this level requires the knowledge of the relations that its objects must set.

Previous time we saw the composition, between the two involved classes Employee and Document.

To summarize: while an employee object can exist by itself and can have one or more documents, the document object cannot exist by itself and can only belong to an employee.

...continue reading "Aggregation of Classes"

Pages: Page 1, Page 2, Page 3, Page 4