Entrevista de Emprego

Um ótimo texto sobre carreira e entrevistas de emprego, visto no Teorias Cobalísticas, creditado ao grande Max Gehringer:

Quem mandou perguntar?

Há anos, com a coloboração de colegas recrutores de pessoal, eu venho colecionando respostas reais dadas por candidatos a emprego. Mas só recentemente descobri que a coleção pode ter a finalidade prática de confortar os aflitos. Quando alguém diz: "Não sei, acho que fui mal na entrevista", e aí vê essas preciosidades verbais, percebe que não foi tão mal assim. Alguns exemplos:

Entrevistador - E então, você está construindo uma networking?
Candidato - Veja bem, eu não sou engenheiro, sou administrador.

Entrevistador - Como você administra a pressão?
Candidato - Ah, tranqüilo. 1 por 7, no máximo 12 por 8.

Entrevistador - Manter sempre o foco é muito importante. E me parece que você tem alguns lapsos de concentração.
Candidato - O senhor poderia repetir a pergunta?

Entrevistador - Como você se sente trabalhando em equipe?
Candidato - Bom, desde que não tenha gente dando palpite, me sinto muito bem.

Entrevistador - Como você se definiria em termos de flexibilidade?
Candidato - Ah, eu faço academia. Sou capaz de encostar o cotovelo na nuca.

Entrevistador - Nós somos uma empresa que nunca pára de perseguir objetivos.
Candidato - Que ótimo. E já conseguiram prender algum?

Entrevistador - Vejo que você demonstra uma tendência para discordar.
Candidato - Muito pelo contrário.

Entrevistador - Em sua opinião, quais seriam os atributos de um bom líder?
Candidato - Ah, são várias coisas. Mas a principal é ter liderança.

Entrevistador - Noto que você não mencionou sua idade aqui no currículo.
Candidato - É que eu uso óculos, e isso me faz parecer mais velho.
Entrevistador - E qual é a sua idade?
Candidato - Com óculos ou sem óculos.

Entrevistador - Quais seriam seus pontos fracos?
Candidato - Ah, é só o joelho. Até tive de parar de jogar futebol.

Entrevistador - Há alguma pergunta que você queira me fazer?
Candidato - Eu parei meu carro aí na rua. Será que eu vou ser multado?

Entrevistador - Por que, dentre tantos candidatos, nós deveríamos contratá-la?
Candidato - Eu pensei que responder a isso fosse seu trabalho.

Entrevistador - Como você pode contribuir para melhorar nosso ambiente de trabalho?
Candidato - Bem, eu começaria trocando a recepcionista, que é muito feia.

Entrevistador - Quando digo "sucesso" qual é a primeira palavra que lhe vem à mente?
Candidata - Pode ser duas palavras?
Entrevistador - Pode
Candidato - Milho. Nário.

Entrevistador - Várias pessoas que se sentaram aí nessa mesma cadeira hoje são gerentes.
Candidato - Puxa, o fabricante da cadeira vai ficar muito feliz em saber disso.

Tentei verificar se esse texto é mesmo de autoria do Mr. Max (em tempos de Internet, o que mais se vê é texto creditado erroneamente), mas o máximo que consegui foi esta página, creditando o texto ao Max Gehringer, e dizendo que fora publicado na revista Exame.

Listas em Cache - problemas

Como eu já havia comentado no post anterior, e o comentário do Carlos reforçou, ao se usar listas ou arrays do Caché, temos o problema do tamanho destas. Como o Carlos bem falou, quando estamos inserindo itens numa lista em memória, tudo ocorre bem. O problema é quando vamos salvar a classe que mantém essa lista.

Por que disso? A resposta passa por como o Caché persiste os objetos. No post anterior comentamos que as listas/arrays são do tipo serial, herdando de %SerialObject. Isso quer dizer que elas vão "embutidas" dentro de outros objetos ao serem persistidas, ou seja, essas classes não têm um ID próprio.

Olhem como fica um objeto persistido da classe que o Carlos passou no comentário, contendo no exemplo abaixo, uma lista com dez elementos:

^Teste.EstouroD(1) = $lb("",11,$lb(1,2,3,4,5,6,7,8,9,10))

Note como a lista vai "serializada" dentro da classe. Como no Caché um objeto persistido é na verdade um valor numa global, e valores nas globais são basicamente grandes Strings, ficamos limitados a objetos menores que 32Kb no total, já que esse é o limite de uma String (pelo menos até a versão 5.2).

Se tivermos uma classe com muitas propriedades, e cada propriedade for muito grande, se esse objeto for serializado dentro de uma lista, o tamanho da lista vai ficar ainda mais enorme. Nestes casos, vale a pena deixar a classe persistente, assim na lista vão ficar guardados os IDs dos objetos, e não os objetos em si serializados.

De qualquer jeito, se a sua lista contiver muitos valores, o erro deve persistir. Nestes casos, o negócio é abandonar um pouco a abordagem OO e partir para gerenciar dados nas globais mesmo.

P.S. Em outro comentário, o Carlos fala sobre o %System.Encription, pra resolver os problemas em relação a criptografia em Caché. Realmente, eu não tinha visto essa classe, e o help não ajudou muito, pq eu havia procurado pelo DES, e a classe só tem suporte para o AES (considerei o DES como sendo o menor denominador comum em casos de criptografia, por ele ser um dos mais antigos, bem documentados e relativamente fácil de implementar).

No caso, o AES não iria adiantar, porque no lado cliente, só tinhamos suporte pro DES. Mas, fica aqui a dica.

Não se trata disso

Resposta genial, ilustra muito bem a sociedade e o tipo de educação que temos hoje em dia, retirado do blog Circuito Integrado da Folha:

Cerf estava em uma conversa, digamos, mais animada com um dos participantes da mesa, que argumentava que o Google deveria filtrar o conteudo usando a qualidade e credibilidade como criterios tambem.

"O Google nao se trata disso", disse Cerf.

"Mas para meu filho de nove anos o Google eh a verdade, ele diz: esta no Google", --rebateu o palestrante.

"Entao o problema nao eh com o Google, eh de criacao", rebateu Cerf, para aplausos de partes dos presentes e constrangimento de outros."

(Velhinho esperto - foto retirada da biografia no ICANN)

Só pra constar, Vinton Cerf é um dos vice-presidentes do Google, e um dos criadores do TCP/IP, que é uma das bases da Internet, ou seja, que possibilita vc ler isso agora.

Listas em Cache

Listas em Caché - abordagem orientada a objeto

Ao contrário do Java, no Caché da Intersystems não temos uma grande API quando se trata de estruturas de dados de coleções (listas, filas, conjuntos, árvores, etc). De fato, quando trabalhamos com orientação a objeto no Caché, basicamente existem dois conceitos de coleção: as listas e os arrays.

Vamos verificar então o que listas e arrays significam para o Caché. Listas são, como o nome bem indica, listas de objetos (como aqueles que você escreve) ou de tipos básicos (como %Integer ou %Float). Cada elemento de uma lista é associado a uma posição da lista. Neste caso, listas em Caché são bem parecidas com listas em Java (em termos de interface, de implementação não dá pra comparar bem, já que em Java podemos ter listas como ArrayList ou LinkedList.

Em Caché, a classe abstrata %Collection.AbstractList fornece a interface básica pela qual podemos trabalhar com listas. Adaptada da documentação, o código abaixo ilustra a criação de uma lista, quatro inserções de elementos nesta lista, e como podemos percorrer a lista, recuperando seus elementos:

; instancia nova lista
 Set list=##class(%ListOfDataTypes).%New()
 ; adiciona quatro elementos na lista
 Do list.Insert("DArtagnan")
 Do list.Insert("Athos")
 Do list.Insert("Porthos")
 Do list.Insert("Aramis")
 ; percorre a lista
 For i=1:1:list.Count()  Write list.GetAt(i),!

Arrays no Caché, por outro lado, são bem diferentes do que o nome pode sugerir (pelo menos pra mim, que vim de linguagens como Java, Pascal, C/C++). Arrays do Caché são como objetos da interface Map do Java, eles necessitam além do elemento a ser guardado na estrutura (objeto ou tipo básico de dados), uma "chave" associada, para você acessar o elemento. Essas estruturas são muito úteis ao implementar coisas como tabelas de Hash, assim como a Hashtable.

Nada melhor que um exemplo para esclarecer, por isso vamos ver o exemplo adaptado da documentação da classe %Collection.AbstractArray, que serve como interface para as classes de array no Caché:

; instancia um objeto array 
 Set arr=##class(%ArrayOfDataTypes).%New()
 ; coloca itens no array - o segundo parâmetro é a "chave"
 Do arr.SetAt("red","color")
 Do arr.SetAt("large","size")
 Do arr.SetAt("expensive","price")
 ; iteração no array
 Set key=""
 For  Set value=arr.GetNext(.key) Quit:key=""  Write key,":",value,!

(Notem que o método SetAt, correspondente ao put do java.util.Map, tem os parâmetros invertidos com relação a este, enquanto no put a chave vem como primeiro parâmetro, no SetAt a chave vem no segundo.)

Em ambos exemplos acima, usamos tipos de dados básicos como elementos nas lista e array, mas poderíamos ter usado objetos. Para isso, ao invés de termos usado %ListOfDataTypes e %ArrayOfDataTypes, usaríamos %ListOfObjects e %ArrayOfObjects, respectivamente.

Quando usamos coleções como propriedades de classes, podemos ou declarar a propriedade explicitamente como objeto das classes de Array/List (como faríamos como qualquer outra classe), ou então podemos declarar assim:

    ; uma lista de %Strings: 
    ; em vez de: Property Colors As %ListOfDataTypes 
    Property Colors As List Of %String

Vale lembrar que esses objetos arrays e lists são do tipo Serial, ou seja, herdam de %SerialObject, e que portanto vão "serializadas" dentro de outra classe, se forem persistidas. Se a sua lista for muito grande, ou mesmo que a lista não tenha muitos elementos, mas os seus elementos sejam %SerialObject, pode ocorrer um erro de MAXSTRING.

Considere a classe abaixo:

Class Teste.Estouro Extends %Persistent [ ClassType = persistent ] {

Property lista As list Of %String;

ClassMethod teste(qtde as %Integer) 
  {
    set a = ##class(Teste.Estouro).%New()
    w a.%Save()
    For i=1:1:qtde  {
        do a.lista.Insert(i)
    }
    w a.%Save()
  }
}

Experimente chamar de uma janela de terminal o método teste, passando diferentes valores. Ao se passar uns 10000, você já pode conferir o erro de MAXSTRING. Lembrando que isso vale para versão 5.2 do Caché. Ouvi dizer que na versão 2007, o limite de tamanho de Strings aumentou, então esse tipo de erro deve ocorrer menos frequentemente, mas não cheguei a verificar na documentação isso.