iMasters

Dando continuidade, demonstraremos outros comandos que podem auxiliar nossos usuários, administradores Linux e entusiastas de distribuições baseadas nos pacotes rpm. Iremos abordar “a ponta do iceberg” de comandos rpm.

 1. Como listar pacotes instalados recentemente

2. Listar todos os pacotes instalados recentemente

3. Como realizar “upgrade” de um pacote rpm

4. Removendo um pacote rpm

Neste exemplo, não há necessidade de explicitar todo o caminho do pacote (ex. nx-3.5.0-2.el6.centos.i686.rpm), somente as iniciais do mesmo. Para realizar o procedimento iremos utilizar a opção -e (erase):

5. Como remove um pacote rpm sem dependências

Ao utilizar a opção – nodeps (não checar dependências) forçamos a remoção de um pacote rpm. Mas, tenha cuidado, esse tipo de remoção pode parar outras aplicações.

6. Exibe o pacote dono do arquivo /usr/bin/htpasswd

Estamos apresentando os principais comandos rpm para um gerenciamento eficiente de pacotes rpm. Se você tem sugestões, dúvida envie no email ludolf@sejalivre.org.

Obrigado e até a próxima!

Continuando o assunto de artigos anteriores, iremos apresentar as variáveis pré-definidas, bem como, dissecar sobre assunto supracitado apresentando alguns “pulos de gato” ao nosso leitor.

Variáveis pré-definidas

São variáveis do Bash que armazenam informações sobre a sessão corrente. É possível atribuir valores a variáveis para que fiquem no ambiente de um subprocesso (comando) particular, da seguinte maneira:

Exemplo:

PATH=/root/sis progs02

Fará com que o programa progs02 seja procurado e executado a partir do endereço /root/sis.

Variável-descrição

    DISPLAY – Determina em qual display do X o programa deve exibir suas janelas;

    HISTFILE – Caminho para o histórico de comandos do usuário;

    HISTFILESIZE – Número máximo de linhas do history file;

    HISTSIZE – Número máximo de comandos a ser mantido;

    HOSTFILE – Contém o nome de um arquivo no mesmo formato

    que o arquivo /etc/hosts, lido quando o Bash precisa completar

    um nome de um host.

    HOSTNAME – Nome do host corrente;

    HOME – Caminho para o diretório pessoal do usuário;

    LOGNAME – O nome que o usuário usou para entrar no sistema;

    PWD – O diretório atual;

    TMOUT – Quando tiver maior que 0, este será interpretado como o número

    de segundos que o Bash esperará por uma entrada, após ter exibido o prompt.

Outras variáveis embutidas no Bash funcionam como comandos, devolvendo valores largamente utilizadas em scripts:

$! : PID do último processo executado;

$$ : PID do shell atual;

$? : Retorna o valor 0 se o último comando foi bem sucedido, ao contrário, retorna o valor 1;

~ : Corresponde ao diretório pessoal do usuário atual;

~marcos: Corresponde ao diretório pessoal do usuário chamado marcos.

Comandos sequenciais

A grande maioria das tarefas depende da execução de mais de um comando. Na execução de três comando em sequência, independente do resultado de cada um, utiliza-se o formato:

comando1 ; comando2 ; comando3

Executar o comando mediante o anterior for bem sucedido:

comando1 && comando2 && comando3

Executar o comando mediante o anterior não for bem sucedido;

comando1 || comando2 || comando3

Próximo artigo iremos falar sobre referências e manuais. Não perca!!!

Dando continuidade ao assunto iniciado no artigo anterior, iremos continuar “dissecando” o assunto de forma clara e concisa. Vamos, também, apresentar como trabalhar com as variáveis no Bash.

As variáveis usadas no shell são  semelhantes às usadas em linguagens de programação. Os nomes de variáveis são limitadas à caracteres alfanuméricos. Para criar ou modificar uma variável, não devem ser usados espaços:

VARIÁVEL=VALOR_DA_VARIÁVEL

As variáveis prestam-se à armazenagem de valores. Pode-se dizer que, basicament,e existem dois grupos de variáveis: as do usuário e as de Bash. As variáveis do usuário são aquelas criadas pelo próprio usuário (é óbvio) em shell scripts, em funções ou até mesmo na linha de comando. As variáveis do Bash têm objetivos específicos – algumas podem ser utilizadas pelo sistema, outras podem fornecer informações e tem também as que podem ser alteradas pelo usuário como forma de configurar seu ambiente de trabalho. Existem as variáveis especiais, chamadas de posicionais, que armazenam os argumentos da linha de comando passados a funções.

Escopo de variáveis

• Variáveis locais – São as variáveis definidas no shell corrente. Normalmente usadas em shell scripts;
• Variáveis de ambiente – São as variáveis exportadas automaticamente a todos os subprocessos, incluindo shell scripts, aplicações e subshells. Largamente empregada na passagem de informações;
• Variáveis predefinidas – São variáveis no qual o bash armazena informações da sessão corrente.

Nome de variáveis

Os nome de variáveis pode ser formados pelos seguintes caracteres:

• Alfabéticos (maiúscula e minúscula);
• Numéricos e sublinhados.

É importante atentar para que o primeiro caractere do nome não seja numérico, havendo distinção também entre maiúscula e minúscula.

Exemplo: repo e REPO são variáveis distintas.

Definição de variáveis

As variáveis não têm tipos pré-definidos. Se o valor a ser atribuído tiver mais de uma palavra, deverá ser escrito entre aspas ou apóstrofos. Se for omitida, assumirá valor nulo. Não pode existir espaços entre o caractere =.

Exemplos:

• serv=atenas
• serv1=”GNU Linux”
• serv2=’GNU Linux’

Exportação de variáveis

Define uma variável de ambiente para a sessão e para todas as sessões iniciadas a partir dela.

Exemplo: export PATH=$PATH:/usr/local/bin

Acessando valores

Os valores podem ser exibidos por meio do comando echo. Exemplo:

• echo $nome1
• echo $repo

Removendo variáveis

As variáveis são eliminadas através do comando unset:

unset -v nome2

Com isso, apresentamos as variáveis e seus recursos dentro de um ambiente shell. Para um melhor aprendizado, é interessantepratir para fixar o conhecimnto.

***
Artigo de Deividson Ludolf

Dando continuidade aos nossos objetivos, iremos abordar sobre como trabalhar na linha de comando. Vamos detalhar o tema e apresentar as melhores práticas dentro do assunto.

A maneira mais comum de um usuário ou administrador interagir com um sistema Linux é através da linha de comando. A mesma apresenta um prompt do shell, indicando que o sistema está pronto para ser utilizado, podendo o prompt ser apresentado com $ indicando que é usuário comum ou caractere #, indicando ser usuário root.

Shell

É o módulo que atua como interface entre o usuário e o sistema operacional. Possui um conjunto de comandos internos (built in) que permite ao usuário solicitar serviços do sistema operacional. Implementa também uma linguagem de programação que dispõe de comandos de decisão, de controle de fluxo, funções etc, permitindo a elaboração de pequenos programas, denominados shell scripts.

O shell é um programa independente do kernel favorecendo, assim, o desenvolvimento de vários shells ao longo da história do Unix. Entre os programas interpretadores de comandos pode-se destacar o bash, ash, csh, tesh, sh.

O que é o Bash

É um dos vários shell’s disponíveis em diversas distribuições Linux, em algumas sendo o padrão. O Bash, cujo nome é um trocadilho para homenagear Stephen Bourne, foi desenvolvido para uso no projeto GNU, criado por Richard Stallman, da Free Software Foundation (FSF). Seu propósito é desenvolver um sistema operacional compatível com o Unix e substituir todos os seus utilitários comerciais por utilitários distribuídos gratuitamente. O Bash, como shell-padrão do sistema GNU, nasceu oficialmente em 10 de janeiro de 1988.

Modos de operação do Bash

• Interativo – O prompt é exibido, indicando que o shell está aguardando comandos digitados pelo usuário;
• Não-Interativo - São utilizados arquivos de comandos (scripts) criados pelo usuário para serem executados na ordem encontrada no arquivo de script;
• Restrito – Modo de operação na qual o Bash atua em ambiente mais controlado do que o padrão.

Uma característica interessante do Bash é que ele possui a função de auto-completar os nomes de comandos que foram digitados via entrada padrão. Isso é feito pressionando a tecla TAB; o comando é completado e acrescentando um espaço. Funciona perfeitamente para comandos internos e caso o comando não seja encontrado, o Bash emite um beep.

Teclas de edição básica

As teclas de edição básica tem como finalidade “agilizar” os trabalhos de usuários ou administradores na utilização do terminal.

• Ctrl + B – Move o cursor um caractere para a esquerda
• Ctrl + F – Move o cursor um caractere para a direita
• Del – Elimina o caractere sob o cursor
• Ctrl + D – Equivalente à tecla Del
• Backspace – Elimina o caractere à esquerda do cursor
• Ctrl + _  – Desfaz a última edição efetuada
• Ctrl + X Ctrl + U – Equivale a Ctrl + _
• Ctrl + A – Move o cursor para o início da linha
• Ctrl + E – Move o cursor para o final da linha
• Ctrl + l – Limpa a tela
• Alt + F – Move o cursor para a palavra à direita
• Alt + B – Move o cursor para a palavra à esquerda

Com isso, iniciamos nossos estudos de como trabalhar na linha de comando. No próximo artigo daremos continuidade ao assunto.

***

Artigo de Deividson Ludolf

O entrevistado de hoje é Manoel Veras, professor e especialista em Datacenter. Ele é Doutor em Administração com ênfase em Tecnologia da Informação pela Universidade de São Paulo (USP). Sua graduação foi em Engenharia Elétrica, na UFRN, e o mestrado em Engenharia Eletrônica, na Unicamp.  Além de possuir as principais certificações do mercado de TI, Manoel Veras também é autor de dois livros: Data Center e Virtualização.

Nesta entrevista, ele fala sobre as mudanças ocorridas no datacenter e suas tendências para o futuro e ainda mostra o "caminho das pedras" pra quem quer entrar na área.

Confira!

Get IT UP com Manoel Veras por dfalsarella no Videolog.tv.

---

artigo publicado originalmente no iMasters, por Douglas Falsarella

No último artigo, falamos sobre carreira e as certificações Cisco. Dando continuidade ao assunto, hoje trago uma entrevista com o CCIE Marcello Ishida, que além de falar um pouco sobre as tendências de mercado dessas certificações, aponta também as maiores dificuldades a serem enfrentadas, dando dicas para se conseguir a tão sonhada Cisco Certified Internetwork Expert.

---

artigo publicado originalmente no iMasters, por Douglas Falsarella

Como nós, enquanto profissionais, podemos nos manter atualizados frente às mudanças tecnológicas na internet e nas redes? A Cisco proporciona treinamentos extensivos aos profissionais de TI em todos os níveis, com o objetivo de ajudá-los a alcançar o sucesso e o desenvolvimento através das certificações.

Mas, diante das várias opções, qual escolher? Confira todos as certificações da Cisco e saiba como escolher o direcionamento em sua carreira:

Programa 1 - 2011 - Imasters por dfalsarella no Videolog.tv.

---

artigo publicado originalmente no iMasters, por Douglas Falsarella

A Linux Foundation anunciou que as distribuições Linux das maiores companhias comerciais, incluindo Canonical, Mandriva, Novell, Oracle e Red Hat, estão certificadas com o Linux Standard Base (LSB) 4.0.

Criada pela Fundação para reduzir os custos globais de organizações de apoio à plataforma Linux, a certificação LSB reduz as diferenças entre as distribuições individuais e fornece interoperabilidade, para que as aplicações sejam mais portadas de maneira mais fácil entre as distribuições e sejam melhor suportadas.

Atualmente, a Fundação já trabalha no desenvolvimento da versão 4.1 do LSB e lançou um beta público para ela. Como de costume, conta com o feedback dos usuários para essa versão.

Com informações de Under-Linux

---

notícia publicada originalmente no iMasters, em 13 de dezembro de 2010.

Neste último artigo sobre SCJD, quero finalizar apresentando meu arquivo de decisões arquiteturais, com o qual fui aprovado quando prestei a prova. Vale a pena lembrar que as opções abaixo foram por mim decididas mediante os requisitos e as circunstâncias do meu projeto, não sendo aplicáveis para qualquer outro. O meu objetivo aqui é mostrar para os candidatos interessados um exemplo modelo para que seja usado como "template" - ponto de partida. Outra coisa importante é que as decisões documentadas podem de alguma forma ajudar ou oferecer um "norte" para que os candidatos possam fazer as suas em seus projetos. Volto a dizer que essa foi uma das provas para a qual eu mais tive que estudar, mas que também foi na que eu mais aprendi.

Continuo à disposição para qualquer eventual ajuda.

Design

Architecture

I decided to use 3-layer (GUI->BUSSINES->PESISTENCE->FILE.db) instead of 2-Layer (GUI->PERSISTENCE->FILE.db).

I decided to create a bussines layer between gui and persistence layer because:Loosely coupled Avoid coupling of the details of persistence in the gui layer.

1. Centralization and encapsulation of business rules.
2. Code reuse facilitates the addition of different types of client such as a web application.
3. Independence between layers.
4. Maintainable and extensible.
5. Transparency in data access.
6. Deploy between different host.

Implementation

• The suncertify.db package implements persistence layer.
• The suncertify.bussines package defines polymorphically bussines layer.
• The suncertify.local implements local bussines layer.
• The suncertify.remote implements remote bussines layer.
• The suncertify.view implements view layer.

Designer Patterns

The following patterns were used:

1. suncertify.db.Data implemented Singleton.
2. suncertify.remote.RemoteRoomServiceImp implemented Adapter.
3. suncertify.bussines.Room implemented Transfer Object.
4. suncertify.remote.ServiceFactoryImp implemented Factory.
5. suncertify.view.ConnectionWindow implemented Template Method.

Exception Handling

I decided to create and use object exceptions approach instead of return error codes because:

1. Robust code.
2. Separate the error handling from the application logic.
3. Exceptional conditions can not be ignored because there must always be a catch handler.
4. OOP approach Treated as an object encapsulating all the necessary information.
5. Decreases the complexity.

I created an exception for each layer that was used to isolate the occurrences of exceptional conditions:

• *Persistence Layer: suncertify.db.DataBaseException.
• *Bussines Layer: suncertify.bussines.BussinesException.
• *View Layer: suncertify.view.ViewException.

Server

Network RMI vs. Socket

I decided to use RMI because:

1. Transparency and usability - communication mechanism is completely hidden by technology.
2. Object based semantic - remote objects look and feel just like local objects.
3. Protocol - there is no need to worry about designing protocol between client and server.
4. I did not want implement any mechanisms for remote communication.

Database File Selection

I chose not to let the user choose or change the database file when connected remotely because:

1. The assignment did not mention any requirement on the subject.
2. Avoid increase the complexity of the code unnecessarily.

Shutdown Hook

I decided to implement shutdown hook with Runtime.getRuntime().addShutdownHook() because:

1. Close the database file properly when the application is closed.

Persistence Layer

File Acess

I decided to implement database handler with just 2 classes:

1. suncertify.db.Data implements mandatory interface and manages access to the file.
2. suncertify.db.RecordManager utility class that encapsulates all details about the database schema.

I decided to use RandowAcessFile instead of separate DataInputStream and DataOuputStream classes because alow (it alows?) randow acess to file.

Hard-Code Database Schema

I decided to use hard-code database schema instead of dynamically load because:

1. The assignment did not mention any requirement on the subject.
2. The assignemnt did not mention the possibility of having other types of database files.
3. Avoid increase the complexity of the code unnecessarily.

No Cache

I decided to always read the records directly from the database file instead of using cache approach because:

1. The assignment did not mention any performance requirement.
2. Easy understanding for junior programmers.
3. Avoid increase the complexity of the code unnecessarily.

Database Exception

I decided to throw a RuntimeException (suncertify.db.DataBaseException) instead of encapsulate the errors occurred in the exceptions defined by the mandatory interface because:

1. There were errors that made no sense to throw the exception defined by the mandatory interface.
2. It was not possible to add new exceptions in the mandatory interface.

Magic Cookie

I decided to validate the magic cookie preventing the user  to enter an invalid database file.

The validation implemented was hard-code instead of dynamically because:

1. The assignment did not mention any requirement on the subject.
2. The assignemnt did not mention the possibility of having other types of database files.
3. Avoid increase the complexity of the code unnecessarily.

Primary Key

I decided to use the file position as primary key because:

1. The assignment did not mention any requirement on the subject.

I decided not to reuse the deleted primary key because:

1. The assignment did not say it was mandatory.
2. I decided not to make delete operation for the application.
3. Avoid increase the complexity of the code unnecessarily.

Never Throw DuplicateKeyException

DuplicateKeyException defined in the createRecord(String[] data) method (mandatory interface) will not be thrown resulting from the choice not to reuse the deleted primary keys.

Create Record, Update Record and Delete Record Methods

• I decided not to implement any validation in the fields.
• I decided to fill white space fields with size less than that defined in the database schema.
• I decided to ignore the character of the fields that far exceeded the maximum size defined in the database schema.

Reasons:

1. The assignment did not mention any requirement on the subject.
2. I decided not to make these operations for the application.
3. I decided to implement blocking mechanisms properly as required in the assignment.
4. I only supply basic implementation for these methods due to mandatory interface.

Find By Criteria Method

I decided to use 2 'for' statement and String.startsWith() method instead of regular expression because:

1. Easy implementation.
2. Easy understanding for junior programmers.
3. Avoid increase the complexity of the code.

Lock

I decided to use synchronized methods, Object.notifyAll() and singleton patter approach instead of java.util.concurrent API because:

1. The assignment did not mention any performance requirement.
2. Easy implementation.
3. Easy understanding for junior programmers.
4. Avoid increase the complexity of the code.

Lock Owner

I used the cookie approach to identify the lock owner because:

1. It was specified in the mandatory interface.

Lock Cookie

I decided to use System.nanoTime() to generate lock cookie because:

1. Simple and easy.
2. Secure enough to distinguish one client from the others.

Error Message

I decided to separate all the error messages in a specific class (suncertify.db.PersitenceMessages) because:

1. Facilitate maintenance.
2. Facilitate future translations.
3. I18N simple mechanism that does not increase the complexity of the code.

Singleton Patter

I decided to use the singleton pattern in database management class because:

1. Ensure the creation of only one instance.
2. Properly implement the lock control.

Businnes Layer

Bussines Exceptions

I decided to create a base exception class that represents all the errors occurred within the layer instead of creating several different classes because:

1. Isolate and hide details of the errors internally occurred.
2. Define a communication error protocol based on layer.
3. Avoid creating many exceptions classes.

Error Message

I decided to separate all the error messages in a specific class (suncertify.local.BussinesMessages) because:

1. Facilitate maintenance.
2. Facilitate future translations.
3. I18N simple mechanism that does not increase the complexity of the code.

Tranfer Object Patter

I decided to use the transfer object patter creating a class that wraps the fields of a room instead of using array of String in the signature of the methods.

Reasons:

1. Make a code easier to read.
2. Easy understanding for junior programmers.
3. Improve performance when used in remote mode.

Bussines Methods

I decided not to provide methods to insert, update, delete and unbook because:

1. The assignment did not say it was mandatory.
2. Avoid unnecessary increase in code.

I decided to provide the following methods:

1. getRooms get all rooms.
2. search search room using criteria.
3. book book a room.

I decided to make two separate search methods instead of one because:

1. Make code easier to read.
2. Easy understanding for junior programmers.
3. OOP principles override over logic.

I decided to implement the AND criteria logic within the business layer instead of the view layer because:

1. Avoid coupling of the details of criteria logic in the gui layer.
2. Reuse in different types client such as a web application.

I decided to implement the OR and AND criteria logic with just one method, using an criteria object instead of two separated methods because:

1. In this case, it made no sense, in my opinion, to separate and use overload because I see the search operation with OR/AND as being an unique operation.

Book Method

I decided to implement a validation that checks the availability of the room avoiding:

1. Book override.
2. Data inconsistencies.
3. This is a business rule and should stay within the business layer.

48 Hours Rule

I decided not to implement anything about the "48 Hours Rule" because:

1. The assignment did not say it was mandatory.
2. Avoid increase the complexity of the code unnecessarily.

Adapter Patter

I decided to use the adapter pattern in remote service implementation because:

1. Create a level of separation from the networking approach and application logic.
2. Decouple implementation details of the RMI technology from the of application logic.
3. Code reuse.

Factory Patter

I decided to use the factory pattern in remote service implementation because:

1. Ensure that each remote client connected to the RMI server does not share the same business object.
2. Proper identifier mechanism for lock owner.
3. Reduce the number of remote objects that need be registered.

View Layer

GUI Texts and Error Messages

I decided to separate all the error messages in a specific class (suncertify.view.ViewMessages).

I decided to separate all the GUI texts titles, labels, mnemonics and tool tips in a specific class (suncertify.view.ViewTexts).

Reasons:

1. Facilitate maintenance.
2. Facilitate future translations.
3. I18N simple mechanism that does not increase the complexity of the code.

Template Method Patter

I decided to use the template method pattern in a GUI super-class because:

1. Define general skeleton of an algorithm in an operation, deferring some steps to be defined in sub-classes.
2. Code reuse.

No MVC Patter

I decided not to use the MVC pattern in GUI constructions because:

1. The assignment did not mention any requirement about display data throught multiples sources.
2. In my opinion, it is an overhead to use the MVC and create all the necessary classes in so few GUI operations.
3. Avoid increase the complexity of the code.
4. The bussines layer encapsulates rules that can be reused in different types of clients, such as a web application.

No Background Threads

I decided not to use background threads to deal with the user events, leaving everything to be queued on the event dispatch thread because:

1. The assignment did not mention any requirement on the subject.
2. In my opinion, there is no operation currently available that needs to be executed in another thread.
3. In my opinion, with current available operations, the user can not do anything in the system while performing some action. This may change depending on new business operations added.
4. Avoid increase the complexity of the code unnecessarily.

Look And Feel

I decided only used default java 6 look and feel because:

1. The assignment did not mention any requirement on the subjects.
2. Avoid unnecessary increase in code.

Layout Managers

I decided to use the following layout managers:

1. Default BorderLayout.
2. FlowLayout.
3. GridBagLayout.

Reasons:

1. The assignment did not mention any requirement on the subjects.
2. They were the ones I felt that fit better in the construction of graphical user interfaces.

Input Mask

I decided not to use any input mask, leaving the user type everything because:

1. The assignment did not say it was mandatory.
2. I decided to centralize the implementations of all fields validations in their relevant layer.
3. Code reuse.

List Room GUI Startup

I decided not to load all the rooms in the presentation of the main GUI because:

1. The assignment did not mention any requirement on the subject.
2. Leave that decision to the user to load all the rooms or filter using some criteria.

Others GUI Functions

I decided not to provide insert, update, delete and unbook GUI functions because:

1. The assignment did not say it was mandatory.
2. I decided not to implement these operations in the business layer.
3. Avoid unnecessary increase in code.

General

I decided not to implement anything that would solve the following situations:

1. Lost locks.
2. Dead lock.
3. General lock on the database during the shutdown.
4. Client crashes.
5. Sorting columns.
6. Paging data.
7. Notify view layer about nonrepeatable read.

Reasons:

1. The assignment did not mention any requirement on the subjects.
2. Avoid increase the complexity of the code.

No Log

I decided not to use log because:

1. The assignment did not say it was mandatory.
2. Avoid unnecessary increase in code.

Design

No Code Comments

I decided not to write any code comments because:

1. In my opinion, there was no awkward or complex code that needed it.

Leia os artigos anteriores:

• Certificação SCJD - Parte 01
• Certificação SCJD - Parte 02

*

Nesta terceira parte sobre dicas da SCJD, quero abordar a segunda fase da prova. O chamado Essay consiste em o candidato prestar uma prova escrita de 90 minutos, na qual ele terá que responder, em inglês, algumas questões relacionadas com o desenvolvimento de seu projeto. Os objetivos são:

• Questionar o candidato sobre a coerência do seu entendimento nas questões que o levaram a tomar as decisões descritas no documento de decisão.
• Provar a autoria do candidato no código-fonte submetido na primeira parte do projeto. Ou seja, comprovar se o candidato que está prestando o essay é o mesmo que escreveu o código-fonte do projeto submetido.

Baseado nessa linha de raciocínio, seguem algumas dicas para os candidatos interessados:

1. Faça um resumo escrito de seu projeto, descrevendo os principais pontos arquiteturais: nomes dos pacote e das classes, quantidade de camadas, nomes e localização das interfaces chaves etc. Ou seja, você precisa memorizar as características únicas do seu próprio projeto. Estude bem antes de prestar a prova para que você possa descrever tudo sobre seu projeto, caso seja questionado.
2. Uma dica legal é que você descreva as respostas características (nome de classes, pacotes, interfaces etc) do seu projeto mesmo que não esteja explicitamente questionado.
3. Faça um resumo das opções arquiteturais consideradas, cada uma com seus pontos positivos e negativos, juntamente com o porquê da decisão de um, e não do outro. Estude bem esse resumo, uma vez que o candidato também poderá ser questionado sobre suas decisões.
4. Faça um resumo dos padrões de projetos usados e onde ele foram encaixados.

Na época em que prestei essa certificação, acabei fazendo uma série de estudos e levantei os tópicos mais comuns que podem cair nessa fase da SCJD. Com isso, eu elaborei o meu resumo, relacionando com as opções que eu tive que fazer quando fui aprovado. Para fechar a dica, eu estou disponibilizando aqui o resumo em inglês, para que os candidatos interessados possam ter um template de ajuda:

Architecture

01. Wich options did you consider?

2-tier or 3-tier.

02. What are the advantages & disadvantages?

2-tier advantages:

• the complexity
• development time

2-tier disadvantages:

• Tightly coupled - coupling the details of persistence in the gui layer
• Fat client - information processing is done on the client side
• Increased network stress - all data is transported to the client side
• Hard to reuse codes
• Complicated versions maintenance - application logic is executed on the client - machine (maybe thousands) have to be updated. This can be very expensive, complicated, prone to error and time consuming

3-tier advantages:

• Loosely coupled - avoid coupling of the details of persistence in the gui layer
• Centralization and encapsulation of business rules
• Code reuse - Facilitate the addition of different types client such as a web application
• Independence between layers
• Maintainable and extensible
• Transparency in data access
• Deploy between different host

3-tier disadvantages:

• Increased complexity.
• Risk of over-architecting.

03. Which did you choose? Why?

3-tier because of its advantages.

04. How does it work for your assignment?

• I created a bussines layer between data and gui that centralized all bussines rules.
• Bussines layer was defined by suncertify.bussines.RoomService interface.
• I created two polymorphic implementations of this bussines layer - Local and Remote.
• Local was implemented by suncertify.local.LocalRooomServiceImp class.
• Remote was implemented by suncertify.remote.RemoteRoomServiceImp class.

RMI vs Sockets

01. What are the advantages & disadvantages?

Socket advantages:

• Performace and scalability - less network traffic.
• Full control over threads.
• Easier for a junior programer to understand and maintain.
• Easier to propagate changes to services.

Socket disadvantages:

• Don't have protocol - must be writte a custom one.
• Tedious to implement - Write a lot of code to controls sockets and spawn threads to each client connected.
• Responsibility to write multithreaded sever.
• Type-unsafe - Errors can be caught in runtime.

RMI advantages:

• Transparency - the communication mechanism is completely hidden by technology.
• Object based semantic - remote objects look and feel just like local object.
• Protocol - there is no need to worry about designing protocol between client and server.
• Type safe - all communication is based on interface and errors can be caught in compile time.
• Multithreaded sever for free.

RMI disadvantages:

• Less performace and scalability:
• Proxy object layer betwen client and server.
• Look up registry.
• Heartbeat messages.
• There is no control over threads.
• Learning curve a little higher (interface,proxy,registries,rmic) than well socket solution.

02. What did you choose? Why?

RMI, because I did not want to spend my time implementing mechanisms for remote communication.

03. Did you create stubs?

Yes, that was mandatory.

04. How did it work for your assignment?

I created an interface called suncertify.remote.RemoteRoomService that extends my bussiness interface and java.rmi.Remote.

Design Patterns

01. Did you use any? Wich? Where?

• Singleton, Adapter, Transfer Object, Factory and Template Method.
• suncertify.db.Data implemented Singleton ? Persistence layer.
• suncertify.remote.RemoteRoomServiceImp implemented Adapter ? Bussines layer.
• suncertify.bussines.Room implemented Transfer Object ? Bussines layer
• suncertify.remote.ServiceFactoryImp implemented Factory ? Remote bussines layer
• suncertify.view.ConnectionWindow implemented Template Method ? View layer.

02. What could you use but didn't ? Why ?

• In my opinion, is an overhead to use the MVC and create all necessary classes in so few GUI operations.
• The bussines layer encapsulates rules that can be reused in different types client such as a web application.
• Avoid increase the complexity of the code.

Locking Mechanism

01. Wich approaches did you considered?

Synchronized methods or java.util.concurrent api.

02. What are the advantages & disadvantages?

Synchronized Methods advantages:

• Easy implemention (for junior programmer).

Synchronized Methods disadvantages:

• No concurrency because it uses exclusive lock on the object - poor performance.
• No guarantiees about next granted thread - JVM select.

java.util.concurrent advantages:

• Read concurrency because it uses many read locks that improve performance (but just one writte lock).
• java.util.concurrent has better performance than the synchronized methods.
• Guaranties about next granted thread.

java.util.concurrent advantages:

• -Complicated implementation (not for junior programmer).

03. What did you choose? Why?

I decided to synchronized methods because:

• The assignment did not mention any performance requirement.
• Easy implementation.
• Easy understanding for junior programmers.
• Avoid increase the complexity of the code.

04. How did it work for your assignment?

I implemented a class called suncertify.db.Data that uses the singleton pattern and marked all persitent methods as synchronized to ensure only one instance and blocking.

GUI

01. What layout managers you use for the GUI? Why?

Default BorderLayout, FlowLayout and GridBagLayout. They were the ones I felt that fit better in the construction of graphical user interfaces.

02. How does the JTable get its data, what table model did you use ?

I created my custom TableModel called suncertify.view.RoomTableModel that extends javax.swing.table.AbstractTableModel. I overrode some methods and add one called getRoom (int index).

03. How did you use event handling?

I dont use MVC cause it is an overhead, in my opinion. I implemented simple listeners approach inside each GUI classes.

Exception Handling

01. Wich approaches did you considered?

Return error codes or throw objects exception

02. What are the advantages & disadvantages?

Error codes advantages:

• Easy and fast implementation.

Error codes disadvantages:

• Degrade quality: code with many conditional statements contains higher errors probability.
• Increase development cost: Bug finding, bug fixing, and testing are all increased by unnecessary control flow complexity.
• Possiblitade ignoring exceptional conditions - error code can be completely ignored.
• Missing information - tells that something went wrong, but not the reason for the failure.
• Increases the complexity.

Throw object exceptions advantages:

• Robust code.
• Separate the error handling from the application logic.
• Exceptional conditions can not be ignored because there must always be a catch handler.
• OOP approach - treated as an object encapsulating all the necessary information.
• Decreases the complexity.

Throw object exceptions disadvantages:

• Performance penalty - used in unusual circumstances and inappropriate manner can make the code a little slower.
• Overuse can increase the code implementation.

03. What did you choose? Why?

To throw object exceptions, because of its advantage.

04. How did it work for your assignment ?

I created an exception for each layer that was used to isolate the occurrences of exceptional conditions.

• Persistence Layer: suncertify.db.DataBaseException.
• Bussines Layer: suncertify.bussines.BussinesException.
• View Layer: suncertify.view.ViewException.

Searching implementation

01. Where and How?

• The suncertify.db.Data class implemented OR logic, as was mandatory. I used two nested commands 'for' and String.startsWith.
• The AND logic was implemented in bussines layer through the suncertify.local.LocalRoomServiceImp class.
• To select between the OR or AND logical, was created a class called suncertify.bussines.Criteria used as parameter.

Phrases Template

• Did I decided to create?
• Did I decided to implement?
• Did I decided to separate?
• Did I decided to use (X) because?
• Did I implemented a class called suncertify.(X) that?
• Did I decided to use (X) instead of (Y) because, in my opinion, there was no need to?

Vale lembrar que esse resumo está relacionado com as decisões e com os requisitos que eu tive que contemplar na minha solução, não sendo uma "Receita de Bolo", uma vez que cada prova cobre diferentes requisitos e situações. Estou à disposição para quaisquer dúvidas. Até a próxima.

---

artigo publicado originalmente no iMasters, Fernando Franzini