| Autor |
Mensagem |
|
|
Oi ssica silva,
Esse algoritmo não é muito fácil de entender, ao menos na minha opinião. Um ponto que com certeza gera bastante confusão neste algoritmo é a recursividade que é utilizada para atingir a ordenação da lista de dados.
Vou te dar uma dica de uma técnica antiga, trabalhosa e extremamente chata  mas muito eficiente para atingir o entendimento deste algoritmo e de vários outros que poderão surgir na sua frente (talvez vc até já saiba fazer isso).
A galerinha das antigas chamavam essa arma (essa técnica) de TESTE DE MESA, vamos lá:
a) Pegue um código que esteja executando sem erros e que esteja lhe apresentado o resultado desejado.
.Este código tem que ser inteligível por você, quero dizer que não pode haver nada de misterioso em termos de códificação. Porque o objetivo é entender o algoritmo e não a codificação.
b) Pegue um folha de papel (uma planilha eletronica poderia ser bastante interessante e prática) e faça uma lista dos dados que você quer ordernar. Esta lista tem que ser igual a que você irá colocar no programa para ordenar.
c) Ao lado de cada item da lista (que vc escreveu no papel) coloque a posição que o item ocupa na lista Ex:
+--+-------------+
| 0 | Cacilda |
+---+------------+
| 1 | Bernadete |
+---+------------+
| 2 | Zuleika |
.......
d) Execute o programa em modo debugger e siga passo a passo a execução.
.Toda alteração que o programa fizer na lista de dados vc altera na mão a sua lista no papel, a sua referencia será os números que vc colocou no lado dos itens, que vc poderá verificar pelo debugger.
Na verdade tudo isso você poderá fazer apenas utilizando o debugger verificando a cada passo do processamento o que aconteceu com sua lista. O problema com isso é que a pessoa acaba se perdendo porque há muita iteração em cima da lista e a idéia das fases vai se perdendo prejudicando o entendimento do algoritmo.
Esta técnica permite que vc tenha uma visão geral e detalhada ao mesmo tempo do que está acontecendo, sem falar que as alterações na lista será você mesma quem estara executando junto com o micro.
Porisso os caras chamavam isto de TESTE DE MESA, porque a simulação da execução era feita na mão.
Desculpe por não ter uma idéia melhor e menos confusa que essa 
System.out.println( "Abraços e boa sorte" );
|
 |
|
|
E ai bbecalli,
Conheço um carinha que desenvolve em Delphi e experimentou o Netbeans, gostou bastante.
As IDEs free mais utilizadas acho que são o Eclipse e o Netbeans, são muito boas.
Eu diria para vc experimentar as duas e utilizar a que mais lhe agradar.
Outro toque é o seguinte....Java não é somente a linguagem, é muito mais abrangente que isso. Portanto fique atento as discussões deste ótimo fórum e outros sites especializados.
Abraços e boa sorte
|
|
|
|
Estou com o windsofhell,
Aliás nas entrevistas eu pergunto para o entrevistador se utilizam geradores de código. Se utilizam, eu descarto a oportunidade.
Geradores de código dizem bastante a respeito de quem utiliza, além dos problemas citados pelo windsofhell. Exemplos: Prazos malucos impostos por gerentes incompetentes, Líderes desorientados que acreditam em milagres ou grande escapadas, gerentes com visão só comercial que se acham espertos demais e por aí vai, a lista de porcarias que isso traz embutidas é gigante.
ATENÇÃO, não é que eu ache isto, EU presenciei (infelizmente) isto.
Estude bastante, tudo o que for possível, para nunca cair na ilusão de que um gerador de código vai te salvar.
Se alguém te disser que sai mais barato, pense no valor das customizações para atender as exceções e nas horas extras (enormes) para fazer uma coisa boba fora do previsto, se o cliente pagar em dinheiro e vc estiver precisando tudo bem (não me fale em banco de horas, combinado?).
System.out.println("Abraços");
|
|
|
|
Oi Bruno,
Carinha, o cenário que vc descreveu me chamou a atenção. Então aqui vai a minha opinião:
Como já disseram antes, e eu concordo, o sócio da empresa pode e deve tomar decisões difíceis para manter ou salvar a empresa mesmo que muitos não concordem com elas (inclusive ele). Espero que o seu caso não seja um daqueles em que o sócio da empresa é um ex programador VB, Clipper, PHP, etc... e esteja valorizando mais as emoções que as questões que envolvem a organização.
Acho que a equipe não tem muita saida, porem, tem que verificar a causa da desmotivação e resolver porque a desmotivação destroi muitas coisas importantes, criatividade é um exemplo. Se a equipe achar que a decisão do líder está errada e que existem alternativas melhores para atingir o objetivo vale algumas reúniões para discutir estas alternativas.
Se vcs preferem java e os lideres preferem PHP e qualquer uma das duas servem para atingir o objetivo sendo que em PHP o custo seja menor. Faça uma avaliação e veja se vc realmente gosta com Java, se java for o que você quer mesmo, tente outra oportunidade em uma empresa que optou por esta tecnologia, mudar para outro projeto em outra empresa não é sinal de fraqueza ao contrario, você estará ajudando a vc mesmo e a empresa que vc está deixando, desmotivação é ruím para TODOS.
Se você e sua equipe gostam da empresa que trabalham e desenvolver em PHP ao invés de java não seja problema e o fator da desmotivação seja simplesmete o fato de estar envolvido com o legado, tente inventar um maneira de deixar o trabalho menos desmotivante. Aplicar tecnicas de refactory, montar um novo fluxo para os processos, tentar atingir uma nova marca na performance, criar um visual mais arrojado são alguns exemplos que pode trazer motivação ao trabalhar com legados.
É isso ai, só queria te falar sobre a minha primeira impressão sobre o seu post.
Boa sorte, acredite isto que vc relatou acontece bastante no mercado, na maioria dos casos a equipe corrente desaparece e uma nova equipe surge no lugar incrementando a grande rotatividade de profissionais nas empresas.
Desculpem se viajei muito no tema rsrsrsr.
System.out.println(  );
|
|
|
|
Oi Diego,
Você pode retirar os zeros a esquerda simplesmente transformando a string em um numérico.
[]'s
|
|
|
|
Oi Diego,
Vou dar uma olhada no código que vc enviou, mas só para adiantar, é o seguinte:
No ponto da gravação dos dados no arquivo acho que você está pensando que realmente será gravado o número que você está enviando. Mas na verdade o java acha que você está enviando um codigo de algum caracter da tabela ASCII.
Segue abaixo uma pequena explicação que consegui na net.
Tipos de dados inteiros
Os tipos de dados primitivos byte, int, char, short e long constituem tipos de dados inteiros. Isso porque variáveis desses tipos podem conter um valor numérico inteiro dentro da faixa estabelecida para cada tipo individual. Por exemplo, um byte pode conter um inteiro entre -128 e 127, enquanto um short pode conter um valor entre -32.768 e 32.767. Já o tipo long é de um tamanho muito extenso.
Há diversas razões para se utilizar um ou outro dos tipos inteiros em uma aplicação. Em geral, não é sensato declarar todas as variáveis inteiras do programa como long. Raramente os programas necessitam trabalhar com dados inteiros que permitam fazer uso da máxima capacidade de armazenagem de um long. Além disso, variáveis grandes consomem mais memória do que variáveis menores, como short.
Tipo caracter
Uma variável do tipo char armazena um caractere Unicode. Um caractere Unicode é um caractere de 8 bits, sendo que de 0 a 225 correspondem aos caracteres do código ASCII (a tabela ASCII é uma tabela padronizada internacionalmente de associações entre caractere e a sua representação numérica no computador).
OBS. O texto diz que o valor máximo no byte é 127 porque o bit de sinal (+-) não foi considerado, isto equivale para os outros tipos também.
Na leitura o método retorna um caracter, ou seja, equivalente a um byte. Porisso que você vê apenas valores menores que 127.
Essa parte é um pouco confusa mesmo, vale a pena fazer uma pesquisa em cima deste tópico.
Fora tudo isso que eu disse antes, vc tem uma letra e um caracter chamado de virgula envolvidos no caso, ou seja; letras, números e o caracter separador utilizado como separador a virgula.
Se você está querendo um arquivo com conteúdo limpo e compreensivel que possa ser aberto em um editor de texto qualquer. Acho que você optou pelo tipo certo de arquivo, mas terá que compatibilizar a estrutura de dados, transformando os números em strings ao gravar.
Se você optar por isso, você terá que formatar os números, porque a string "12", não ocupa o mesmo espaço que "198", isto deveria ficar assim " 12" e " 198" ou "0012" e "0198". Eu faria assim porque eu não posso ler caracter por caracter, se eu fizer isso provavelmente terei o seguinte resultado: 0,0,1,2,0,1,9,8 <--- se estiver formatado.
Aplicando a formatação eu posso ler em bloquinhos de 4 caracteres sem distorser o resultado.
Se eu achar mais coisas eu posto.
System.out.println("Abraços");
|
|
|
|
E ai Cris.
Se é assim, tambem acho que a coisa toda tem que ficar no banco mesmo...
Coisa de louco esse seu menu heim!?!?!?
[]'s
|
|
|
|
Oi .cris,
Uma outra idéia seria utilizar um arquivo xml para descrever o seu menu, é claro que essa idéia só vale se você NÃO odiar xmls. Após a montagem do xml bastaria montar um código para ler este arquivo ou baixar um componente do tipo XStream para ajudar, em se tratando de xmls tem bastante opções para download.
Aliás o componente XStream consegue converter objetos, inclusive os associados e agregados em uma estrutura xml. Este componente é bem fácil de utilizar, olha o link aqui http://xstream.codehaus.org/download.html.
Acho que as chances de vc se livrar das leituras recursivas nesta idéia são mínimas mas existem, mas você não terá o banco de dados envolvido nisso tudo. Você resolverá tudo no código java.
Um ponto que eu acho que pode ser chato nesta idéia é a manutenção do arquivo xml.
Quero dizer o seguinte: para adicionar ou excluir um item você poderia utilizar um editor de texto, mas um pequeno deslise faria o seu componente leitor deste arquivo se perder. Para evitar este problema você poderia construir uma interface para administrar o cadastro do menu (alterar o arquivo xml), ai vc já sabe...é "fritar o teclado até umas horas".
Não sei se deu para perceber mas os preços a se pagar por essa solução são os mais variados possíveis.
É isso ai...só queria dizer que existe outro jeito de entrar neste barco rsrsrsr.
[]'s
|
|
|
|
Oi Diego,
Então....o código que postei na verdade intencionava simplesmente demonstrar a gravação / leitura de números acima de 3 digitos tanto em binário como em texto sem distorções.
Estava dando uma olhada nos pedaços de código q vc postou e entendi que vc grava Inteiros que ocupa 4 bytes (se não me falha a memória) e lê com o método fw.read(). Acontece que este método lê apenas um byte, ou seja, realmente a leitura não irá refletir o que vc gravou anteriormente. Porque você gravou 4 bytes e depois leu apenas 1 byte.
Resumindo...se vc gravar double tem que ler double, se gravar int tem que ler int, se gravar 4 bytes de texto tem que ler 4 bytes de texto dependendo da lógica aplicada.
Estou começando a achar que deve haver problemas no fluxo também.
Isto que eu disse faz sentido? Se fizer talvez seja uma boa idéia postar o código completo, se possível ou um código resumido com o problema isolado pra gente dar uma olhada. 
um Java abraço....
|
|
|
|
Oi ykschmitt,
Dei uma olhada rápida no seu código e percebi o seguinte:
1) Na linha 10 ->> "class CalcSOMA extends Frame"
Você poderia trocar a classe Frame por JFrame.
2) Nas linhas 44,48,52,56,60,64
Incluir na frente dos adds o painel "quadro" desta maneira: Ex. quadro.add(btn1);
Esta alteração irá fazer com que os botões apareçam.
Por enquanto é isso.
P.S. Ao executar provavelmente irão surgir duas janelas, confesso que achei isso estranho rsrsrsr.
Abraços
|
|
|
|
|
Preparado para "liderar"!
|
|
|
|
Oi Cris, tô gostando do seu estilo .
Posso criar lá no banco as tabelas:
Modulo que pode ter 1 ou mais Menu
Munu que pode ter 1 ou mais Submenu
Submenu que podem ter 1 ou mais Tela
Agora como eu faço para que esse nível de Submenu não seja fixo? Relaciono Submenu com ela mesma?
Tem alguma idéia?
Essa sua idéia na minha opinião funciona, e o submenu ficará flexivel. Obviamente o ponto de complexidade está na tabela "submenu". Você pode resolver isto com leituras recursivas, ou seja, toda vez que você ler uma linha (subitem de um menu) da tabela "submenu" vc terá que ler a tabela novamente para verificar se este item possue itens.
Parece que existe uma outra maneira de resolver esta questão, mas não lembro agora.
Se postar a estrutura das tabelas talvez apareça mais algumas idéias.
Tô torcendo por vc...
[]'s
|
|
|
|
Olha eu de novo Diego,
Segue abaixo o código que grava/lê números em arquivo texto:
|
|
|
|
Oi Diego,
Segue abaixo o código que executei na minha máquina, fiz o teste com 5 mil números:
vou verificar as partes de código que vc enviou.
[]'s
|
|
|
|
Oi Cris,
Eu lí os posts que você apontou....
Entendi que vc está precisando montar uma estrutura de segurança altamente personalizada, logo, acho que coisas com o acegi por mais que eles lhe ajudem não será suficiente. Na minha opnião estes componentes são bons mas não fornecem facilidades no nível de detalhe que vc precisa, ou seja, você terá que "ralar" e construir "na unha" a solução.
Entendi também que no momento vc está envolvida com a estrutura dos menus, acho que você está no caminho certo. Se a minha percepção tiver correta você terá 2 grandes desafios: Montar a estrutura de dados e Montar os algoritimos para administrar esta estrutura. Se é isso mesmo, vc poderia postar a sua ideia inicial da estrutura de dados (MER) para ser criticada até chegar em um nível que vc ache bom.
Desculpem se voei muito no tema...
[]'s
|
|
|
|
|
|