terça-feira, 16 de dezembro de 2008

Ruby scripts

Hello all!

As I have promissed I will post here some Ruby scripts, nothing really amazing but I thing that it could be a nice startup for Ruby studing and it could be useful for someone.

The purpose of the script is to generate random files, with fixed record size (like those used by COBOL programs). The zip has three files:
  • FileCreator.rb: the program itself, it is responsible to create the file, you script should refer to it;
  • TestFileCreator.rb: the test case, we never forget about it; and
  • CreateFile.rb: an example of how to use the program, it is the script itself, if you want to run something start with this.
You can download it here.

I hope it could help you somehow.

See you soon!

sábado, 13 de dezembro de 2008

I don't need to say a word

Rails 2.0 and scaffolding

One of the most interesting Rails tool is the scaffolding, but when you look aroung the internet you notice that almost all the tutorials refers to the Rail 1.x.
Unfortunetly there were a lot of changes in this tool. Sean Lynch wrote this nice tutorial about version 2.0: Rails 2.0 and Scaffolding Step by Step.

sexta-feira, 12 de dezembro de 2008

Ruby roadmap

I am new at Ruby development and I AM not sure that it could solve the Global Warning problems, but it could be a nice to tool to have in your pocket.

For example, yesterday I needed to extract some data from a bulk of files, so I created a one shoot script that help me a lot.

 

I will not post here the script that I created, it will not help anyone but I will write down a Ruby roadmap, if you are a beginner it could help. First of all we need to understand that Ruby is just a language, it is not related to web stuffs or things like that; but now you come as say: “But my little friend said that Ruby is a boost for web application, you are a liar, your… your.. fool!”

Take easy little boy, I will explain it  to you: the magical word for web is Ruby on Rails. But what is it? Rails is the underline framework for Ruby that makes web development easier, because of the conventions that it is based on.

 

First step you should go to the  website: Ruby on Rails, go directly to the Get Started. There you will be able to download the Ruby and get the instructions to install the Rails, I recommend that you install both (it doesn’t matter if you are going to do scripts or web development).

Once you get your environment running make the first application (suggested at the Get Started), after that you should make a difficult decision: learn the language or keep running in a nice tutorial. I am for make a nice tutorial, but I will let you choose:

·         Learn language: This is the most crazy book for programming language that I have seen so far, but it worth a look: why's (poignant) guide to Ruby. It will give you a nice overview of the Ruby language, there isn’t any web reference here.

·         Tutorial: there is plenty tutorials about Ruby on Rails in the internet, but I suggest these: Getting Started With Rails, Tutorial Step One (wiki). The last one is more direct, although the text is a little bit confusing.

I think that it is a little bit amount of data to start with Ruby. Just move yourself little boy and start learning it, next I am going to post a Ruby script to create fixed file size for testing.

terça-feira, 9 de dezembro de 2008

NO! NO! NO!

It is not normal to me to post something in the middle of the day, but this morning I’ve listened so much insanity that I need to write it down.

I swear that in the next post I will write something technical, but there is so much crazy people around that I need to let it here, before I get mad too.

Here is the situation: there is a web system here, that I will refer as GlubGlub that was audited by a big company, concerning security issues. They raised a lot of point to improve, so far so good (I will not discuss the audit here).

Between the issues there is a point regarding passwords, the site was the normal password field. But it is wrong, it is a big issue hole, although the site uses SSL.

And now the people come with the most incredible ideas to solve a hole that no one tries.

I will use as example banking applications, because I believe that those guys are woried about this kind of issue. At the beginning there is just fields there, but the people were falling in some kind of keyboard recorder. Then they decided to make a virtual keyboard and block typing: problem solved.

I know that it is not 100% safe, but if it is good for the banks it is good to most of us.

The lesson here is: we should look around before starting with solutions that uses things like Javascript that I can disable in the most stupied browser.

I am starting to believe that the microwaves around us are burning our brains.

sexta-feira, 5 de dezembro de 2008

When the people that should know, doesn't know!

Today I’ve spent some time reading a set of documents at the company. It is incredible how official documents and manual has a lot of misunderstanding, things take lead to a wrong set of concepts and ideas.

It is important to have good concepts and solid knowledge, mainly to use the tools available for us. In this post I am showing small phrases and I would like you to read it carefully, you will face some amazing texts (by the way, I have translated them to English). 


The PowerDesign implements a Use Case Diagram and its objects using a OOM – Object Oriented Model. It was defined by the Methodology that all the Systems will have a OOM, called CAU (Use Cases), and all the functional requirements specification will be inside of this model.

First of all, you cannot implement a Use Case Diagram in a tool, what the tool does is: provide ways to modeling a Use Case Diagram and write a Use Case Specification. Next, Use Cases are not related to Object Oriented Modeling, they are related to UML (Unified Modeling Language), they are used to describe the responsibilities and boundaries of the system.

At the last, functional requirements are not Use Cases or vice-versa, when you put them in the same level you end up having a functional decomposition. Absolutely you don’t have a use case for each functional requirement. Use Cases represent what the actor wants from a system, not the functions of the system.

Lately we will see an example of it.


In truth, the Object Oriented Analysis is quite simple. Their concepts are closer to the human comprehension than the essential or structured analysis. In fact their functional definition is oriented to the user comprehension of the system, which doesn’t need to have any technology concept.

It is true that OOA is not related to technology concepts (I am assuming as technology concepts: programming languages, SQL, etc), as it isn’t true that the user can comprehend OOA. You should remember that it is a set of concepts and normally notations that you must know to understand it.

So at the end you cannot show it to your user, unless he know the concepts.

In fact their functional definition is oriented to the user comprehension… well I don’t know why it is true? What do we have is a highlight in the objects of the system, but if it is not well modeled the OOA will not show the user comprehension of the system. If you do the right thing doesn’t matter the tool, it will be right.

The benefits of the OOA are others like abstraction, where you can first look at a high level, and getting deeper and deeper as you know more about the problem scope (but I should say that it is not the only benefit).


The resistance to the Object Oriented Analysis happens because most of the people look at it as something advanced. In fact it has extraordinary concepts, for example, it is possible to automate the code creation 

OOA = automate code creation? What kind of insanity is it? You could say that from UML tools can generate code for you, but OOA, no way. From a language you could generate another language, doesn’t matter if it is OO or not.

Code generation is sure before OOA and it is not limited to that, for example: BPMN (Business Process Modeling Notation) is not OO and can be used to generate code.


But to create the methodology documents will be necessary only a small part of the Object Oriented Analysis, the Use Cases. That were already being made in the old documentation, although it was called as Requirements by functionality. 

I will say it again: Use Cases are not OOA. If someone makes just Use Cases he doesn’t need to know anything about object. And again: functionalities are not Use Cases.


All the modern tools for system modeling, among them the PowerDesigner, implement the UML

You don’t implement UML, you provide tools to draw, write, read, do whatever with UML, but it cannot be implemented.


In short, each system functionality must have a Use Case, describing how the user will interact with the system, in the strict context of the functionality.

Use Cases are NOT functions. A Use Case represents a situation where the user uses the system, to use the system a user can interact with one or more functions of the system, and a function can be used in one or more use cases, simple as that.

When you put them in the same level, you end up with a lot of small Use Cases that aren’t really cases. 


…The UML says that its name may have any amount of letters, numbers and most of the special characters. As we saw, to the Methodology the rules for naming are: CAU-[Verb in the Infinitive + Object]. Let’s take the Order as example:

                CAU-Make Order            CAU-Verify Order           CAU-Cancel Order 

First: Use Cases are not bind to specific objects. One of the first steps in OOA is to extract objects from a Use Case (when we are using Use Cases), so you cannot name them by their objects, mainly because a Use Case will interact with more than one object at the same time.

Second: Creating  Use Cases like Make Order, Verify Order, Cancel Order, Whatever Order means that we are writing functionalities and Use Cases. In this situation the user is interested in managing his Order, so we should have something like Manage Order; put yourself as a user and imagine what do you want from the system: you want something that allow you to manage your order, so it is your Use Case. For sure inside of this Use Case you will make, verify, cancel, delete the order.

In that situation you could have another Use Case that is something like Audit Order (it is reasonable that the user wants to get information from the Order and some processing on that, so you will have another Use Case).

As people say: not too much to heaven, not too much to hell.

 

An actor could be anything that communicates with the system. An actor could be the system user, but it could be an equipment, another system, a paper, and so on. The actor always interact with the system, but it doesn’t belong to it.

Actor are things that interact with the system, for example data bases are not actors (but they communicate with the system). And I cannot imagine how a paper could be an Actor. It is important to have it clear, otherwise you end up with Actors like, reports, screens, and things like that.

We should imagine an Actor as someone interested in your system, like the user, another system that receives data from us, and so on.

quarta-feira, 3 de dezembro de 2008

Test on demand???

It looks strange, but it is true! There is a company at USA that offers a test on demand.
They are a pool of testers, you registry your software that and they test it for you.
I don't know if it works, but it is a new idea.

Take a look at their site: uTest, also there is a article TestCrunch that talks about this company: uTest raises $5 Million More For Crowdsourced Bug Testing.

Interesting isn't it !?!