Um desafio de programação é interessante pois ficamos inclinados a demonstrar capacidade, o que pode levar a complexidade artificial e prejudicial.
O projeto foi desenvolvido em TDD, o que pode ser conferido pelos commits. A biblioteca de testes que utilizei foi pytest, primeira vez que a uso, estou aproveitando a oportunidade para aprender seu funcionamento.
Aproveitei a oportunidade de fazer este projeto para utilizar uma série de ferramentas que eu estava querendo testar: além de py.test, esta é a primeira vez que efetuo deploys na heroku, primeira vez que utilizo django-rest-framework, encontrei uma forma de criar mockups de APIs através de um serviço. Infelizmente esta decisão pode ter algum custo, pois como não tenho larga experiência com estas ferramentas, talvez algumas decisões arquiteturais não tenham sido as melhores. Entretanto ela demonstra habilidade e desenvoltura para aprender.
A ideia é descrever um serviço onde as pessoas registram seus bilhetes, e conseguem verificar se o seu bilhete foi sorteado. O servidor Bob gerencia os sorteios enquanto Ana faz a interface com o usuário.
Nestes serviços, um sorteio é representado pela data em que ele irá ocorrer (draw_date), e o ticket de um usuário é representado por uma lista de 6 números.
O sistema como um todo não está com muitas validações, ele é um pouco ingênuo
Há basicamente dois perfis de usuário previstos, o primeiro deles é o usuário consumidor que irá criar bilhetes e conferir se suas apostas foram sorteadas (utilizará as 3 urls abaixo, como uma API REST). O url do sistema para usuário consumidor é http://onyo-ana.herokuapp.com, e terá as seguintes endpoints.
- POST /power-ball/v1/ - Mostra data dos sorteios
- POST /power-ball/v1/create/ - Cria um novo bilhete
- POST /power-ball/v1/check/ - Verifica se algum bilhete foi sorteado
O gerente dos sorteios, que terá acesso administrativo e terá controle sobre os sorteios. URL http://onyo-bob.herokuapp.com. O acesso administrativo será feito pela url http://onyo-bob.herokuapp.com/admin (usuario: admin senhao: onyoonyo).
Além disso, o sistema administrativo tem seus próprios endpoints para se comunicar com sistemas clientes:
- POST /power-ball-core/v1/ticket/create/ - Cria um novo bilhete
- POST /power-ball-core/v1/ticket/check/ - Verifica se algum bilhete foi sorteado
Project Ana
[OK] Teste de integração para checar um bilhete
[OK] criar metodo que check bilhete, chamando Bob
[OK] criar método de criar um bilhete
[OK] fazer que o método de checar bilhete veja no banco se está checado
[OK] fazer que ele também va em bob se não estiver checado, confirme, altere no banco
Project Bob
o bilhete vai ser salvo no banco de dados, criar model
criar fixture com alguma regra para popular datas e bilhetes premiados
criar uma url no rest que é uma view na verdade, vai checar e vai retornar
[OK] antes de chamar bob ana deve ter algum tipo de cache (verifica no model, algo assim, confere nos requirements)
[OK] As chamadas de ana para bob devem ser assincronas
tratar caso de ana chamar bob e bob não estar disponivel
criar alguns tratamentos de erro na comunicação ana/bob
[OK] atualmente para cada requisição de criação eu estou criando um novo
prize. devemos ver se um existe na data, se não lançar erro. quem cria um prize é o backend
os métodos em Bob devem ser autenticados, só ana que deve ser pública
Report coverage, pep8
Here we have some challenges for the following areas Backend, iOS and Android. Please feel free to enjoy our challenge and let us know if you have any question.
The main goal of this challenge is to exercise some concepts of API Rest, microservices and integrations. The basic goal is to create two APIs (microservices) using Django Rest Framework or similar web frameworks. These microservices should communicate with each other by JSONs, but should keep their databases separated. Both of them should answer to simple CRUD requests -- Get, Post, Put, Delete. We'll have two APIs, let's consider the first API "Ana" and the second one "Bob". When having a POST to Ana, Ana should perform a request to Bob and will save the answer of Bob on its own database. Bob should have API calls to return random values when its created, so when we have the same input coming from Ana we should have the same answer from Bob. In order to do it, Bob will have to store some data on its own database. The main reason is the needed decoupling between them.
The models, views and business rules may be created at your own criteria. We're interested on the dynamics that these parts will connect to each other.
As a topic we have a few suggestion:
- Bob could serve Postal Code Information (Street, City, State, etc) given a Postal Code it will return information. Ana should consume Bob and propagate its answer.
- Bob could be serving Lotto Check Service. Given 6 number, Bob will tell Ana if its a winner combination or not. Ana should cache its answer in order to avoid calling Bob many times.
Fell free to follow any topic, but please make sure you have understood the purpose of its challenge.
- Unit tests
- Integrations tests
- Documentation
- Deployment (Heroku, Openshift, DigitalOcean)
- Clean, readable, maintainable, and extensible code
- Decoupling on two different folders
- Django Rest Framework
- Interface
- Don't worry about the topic you'll chose to work on. Fell free to work on a confortable topic.
- You should not try to push changes directly to this repository.
The candidate must implement the APIs and send a Pull Request to this repository with the solution.
The Pull request process works this way:
- The candidate forks the repository (should not clone it directly)
- Works on the code using the forked repository.
- Commits and push changes to the forked repository.
- Using the GitHub interface, send the pull request.
The main goal of the challenge is to create an iOS app to fetch the API information of companies and categories and show them according to the provided screenshots.
Company list: http://api.staging.onyo.com/v1/mobile/brand/1/company
- Customized UINavigationBar
- Company list
- Category list
- Follow design on the provided screenshots.
- Asynchronous and on demand image loading
- Dependency management system (CocoaPods, Gradle, ...)
- Minimum iOS version 8.0
- Swift 2.0
- Customized tabs
- API Communication Framework (Alamofire, ...)
- ORM Framework (CoreData, Realm, MagicRecord, ...)
- Image loading and cache Framework (SDWebImage, Alamofire, Fast Image Cache, ...)
- Unit Testing (XCTest, KIF, Kiwi, Quick, ...)
- Functional tests (Appium, UIAutomation, ...)
The frameworks are just a suggestion. You can use any other frameworks and surprise us!
- You should not try to push changes directly to this repository.
The candidate must implement the app and send a Pull Request to this repository with the solution.
The Pull request process works this way:
- The candidate forks the repository (should not clone it directly)
- Works on the code using the forked repository.
- Commits and push changes to the forked repository.
- Using the GitHub interface, send the pull request.
The main goal of the challenge is to create an Android app to fetch the API information of companies and categories and show them according to the provided screenshots.
Company list: http://api.staging.onyo.com/v1/mobile/brand/1/company
- Customized ActionBar
- Company list
- Category list
- Asynchronous and on demand image loading
- Dependency management system (Gradle, Maven)
- Minimum SDK version must be 15
- Tabs (customized or not)
- API Communication Framework (Retrofit, Volley, OkHttp, ...)
- ORM Framework (SugarORM, GreenDAO, ActiveAndroid, SquiDB, ...)
- Image loading and cache Framework (Glide, Picasso, ...)
- Annotation/Dependency Injection Framework (AndroidAnnotations, Dagger, RoboGuice, ...)
- Unit Testing (JUnit, Robolectric, ...)
- Functional tests (Robotium Solo, UIAutomator, Espresso, ...)
The frameworks are just a suggestion. You can use any other frameworks and surprise us!
- You don`t need to worry about the category images height. You can assume that all the images have the same height.
- You should not try to push changes directly to this repository.
The candidate must implement the app and send a Pull Request to this repository with the solution.
The Pull request process works this way:
- The candidate forks the repository (should not clone it directly)
- Works on the code using the forked repository.
- Commits and push changes to the forked repository.
- Using the GitHub interface, send the pull request.