Post by Gio » 01 Feb 2016, 18:16
It is already freely available in the internet. 59 pages. It's in portuguese though (since he is from Brazil).
Quite easy to find, but i'm not going to link it without permission.
Parabéns pelo grau MasterFocus
Li seu trabalho e ficou muito bom.
Em relação ao caso da automação do sistema da secretaria, já fiz alguns scripts para automatizar a inserção de dados em GUIs de sistemas de terceiros aqui na empresa e, como você mencionou, a confiabilidade é um grande desafio quando o software em questão não possui uma rotina de integração própria com softwares externos. Por isso, em um software que não possuia uma rotina de integração com outros sistemas, optei por ter o usuário confirmando os dados digitados na tela antes de cada inserção (bastando clicar no enter, o que não adiciona muito tempo à rotina, mas prende o usuário na frente da tela).
Em um dos softwares que tem uma rotina de integração (através de importação de arquivos txt), no entanto, o resultado foi bem melhor, com a inclusão de centenas de cadastros ocorrendo em segundos (o AutoHotkey simplesmente cria o arquivo texto com os dados a serem importados no padrão definido pelo programador do software e depois o usuário simplesmente lança a rotina de importação do programa).
Finalmente, a melhor de todas as integrações que participei foi uma onde tive acesso ao banco de dados do sistema, o que dispensou completamente a necessidade de lançar qualquer rotina no aplicativo de terceiros, dando-me liberdade para trabalhar a automação da melhor forma possível. Infelizmente, a maioria dos desenvolvedores de software tem medo de dar acesso ao banco de dados de seus aplicativos, mesmo que a informação ali seja de propriedade dos clientes e o candidato demonstre suas qualificações, simplesmente por receio de que isso dê margem a algumas chamadas a mais ao suporte do programa deles.
Acredito que um grande entrave atual à automação de sistemas otimizada é, portanto, o fato de que os programadores criam seus aplicativos sem dedicar um pouco do seu trabalho para possibilitar que outros programadores agreguem valor ao sistema automatizando e otimizando suas rotinas para clientes específicos. Embora eles acreditem que têm razões pra isso (receio de aumento de custos de suporte), findam por limitar seus programas a um estado genérico que atenda a muitos clientes relativamente bem, mas não atende individualmente nenhum cliente da melhor forma possível, o que tira em demasia produtividade e tempo de nossos colaboradores.
Parabéns novamente e muito sucesso na sua carreira de programador.
SpoilerCongratz on your degree MasterFocus
I've read your work and it is actually very nice
Regarding the case of automating the system in the colleges office, i've written a few scripts to automate data insertion in third party software GUIs in my company and, as you mentioned, reliability is a challenge when said softwares have no data communication routines with external softwares. Thus, in a software that had no such routine, i've opted to have the user confirming data typed into the GUI prior to saving it (all he had to do was to click enter every time, which doesn't really add much time to the routine, but ties the user to the screen).
In another software that actually had a routine to communicate data (by importing txt files), however, the end result was much better, with hundreds of data entries being inserted in a matter of seconds (AutoHotkey simply creates a text file with the data to be imported in a pattern that the software programmer had defined and than the users launches the softwares import routine).
Finally, the best of all automation routines that i was involved was in a case where i was allowed access to the systems database, which meant i had no need to launch any routine in the third-party software itself, allowing me freedom to work in the automation however way i found to be best. Unfortunately, most software developers are afraid to allow access to their apps databases, even if the data actually stored is property of their customers and the requiring individual proves to be qualified, simply because they fear that it will somehow increase the calls to their support line.
I believe that a huge obstacle to optimized system automation is, thereby, the fact that programmers create their apps without dedicating some time to allow other programmers to add to their systems eficiency by automating and optimizing its routines for each specific customer. Although they may believe they have reasons for acting like that (like fearing that it will somehow increase their support line costs), they end up limiting their systems to a more standard format that partially satisfies the broad of their customers, but doesn't actually fully satisfies any of them in the best way possible, and that results in a lot of users time and productivity wasted.
Congratulations once again for your work and i wish you to be very successful in your career as a programmer.
It is already freely available in the internet. 59 pages. It's in portuguese though (since he is from Brazil).
Quite easy to find, but i'm not going to link it without permission.
Parabéns pelo grau MasterFocus :thumbup:
Li seu trabalho e ficou muito bom.
Em relação ao caso da automação do sistema da secretaria, já fiz alguns scripts para automatizar a inserção de dados em GUIs de sistemas de terceiros aqui na empresa e, como você mencionou, a confiabilidade é um grande desafio quando o software em questão não possui uma rotina de integração própria com softwares externos. Por isso, em um software que não possuia uma rotina de integração com outros sistemas, optei por ter o usuário confirmando os dados digitados na tela antes de cada inserção (bastando clicar no enter, o que não adiciona muito tempo à rotina, mas prende o usuário na frente da tela).
Em um dos softwares que tem uma rotina de integração (através de importação de arquivos txt), no entanto, o resultado foi bem melhor, com a inclusão de centenas de cadastros ocorrendo em segundos (o AutoHotkey simplesmente cria o arquivo texto com os dados a serem importados no padrão definido pelo programador do software e depois o usuário simplesmente lança a rotina de importação do programa).
Finalmente, a melhor de todas as integrações que participei foi uma onde tive acesso ao banco de dados do sistema, o que dispensou completamente a necessidade de lançar qualquer rotina no aplicativo de terceiros, dando-me liberdade para trabalhar a automação da melhor forma possível. Infelizmente, a maioria dos desenvolvedores de software tem medo de dar acesso ao banco de dados de seus aplicativos, mesmo que a informação ali seja de propriedade dos clientes e o candidato demonstre suas qualificações, simplesmente por receio de que isso dê margem a algumas chamadas a mais ao suporte do programa deles.
Acredito que um grande entrave atual à automação de sistemas otimizada é, portanto, o fato de que os programadores criam seus aplicativos sem dedicar um pouco do seu trabalho para possibilitar que outros programadores agreguem valor ao sistema automatizando e otimizando suas rotinas para clientes específicos. Embora eles acreditem que têm razões pra isso (receio de aumento de custos de suporte), findam por limitar seus programas a um estado genérico que atenda a muitos clientes relativamente bem, mas não atende individualmente nenhum cliente da melhor forma possível, o que tira em demasia produtividade e tempo de nossos colaboradores.
Parabéns novamente e muito sucesso na sua carreira de programador.
[spoiler]Congratz on your degree MasterFocus :thumbup:
I've read your work and it is actually very nice
Regarding the case of automating the system in the colleges office, i've written a few scripts to automate data insertion in third party software GUIs in my company and, as you mentioned, reliability is a challenge when said softwares have no data communication routines with external softwares. Thus, in a software that had no such routine, i've opted to have the user confirming data typed into the GUI prior to saving it (all he had to do was to click enter every time, which doesn't really add much time to the routine, but ties the user to the screen).
In another software that actually had a routine to communicate data (by importing txt files), however, the end result was much better, with hundreds of data entries being inserted in a matter of seconds (AutoHotkey simply creates a text file with the data to be imported in a pattern that the software programmer had defined and than the users launches the softwares import routine).
Finally, the best of all automation routines that i was involved was in a case where i was allowed access to the systems database, which meant i had no need to launch any routine in the third-party software itself, allowing me freedom to work in the automation however way i found to be best. Unfortunately, most software developers are afraid to allow access to their apps databases, even if the data actually stored is property of their customers and the requiring individual proves to be qualified, simply because they fear that it will somehow increase the calls to their support line.
I believe that a huge obstacle to optimized system automation is, thereby, the fact that programmers create their apps without dedicating some time to allow other programmers to add to their systems eficiency by automating and optimizing its routines for each specific customer. Although they may believe they have reasons for acting like that (like fearing that it will somehow increase their support line costs), they end up limiting their systems to a more standard format that partially satisfies the broad of their customers, but doesn't actually fully satisfies any of them in the best way possible, and that results in a lot of users time and productivity wasted.
Congratulations once again for your work and i wish you to be very successful in your career as a programmer.[/spoiler]
