Location: Brazil
Remote: Yes
Willing to relocate: Absolutely. Pretty much anywhere in Europe or USA / Canada would be awesome.
Technologies: C, C++, Ruby, Python, Javascript, Java and anything else
Resume: Experience in high availability / large scale systems. Email me for details.
Email: pedro@pedrovanzella.com
Preferably part-time for now. Any language / framework - I'm a programmer, not a <X> programmer. (Although I prefer Python).
Every machine (which is never online) prints a sum of all votes at the end of the day, and several copies are given out to those who are working the poll site.
So there is a hard copy of the votes, and anyone can check.
> So there is a hard copy of the votes, and anyone can check.
I think it's not enough to have the ability to do a count. It needs to be inherent to the system. Think of it as being similar to double-entry book-keeping.
Otherwise you can come up with situations like that described in the comment elsewhere here by DaviNunes, where a request for a check cound was denied by courts. In that election - it wasn't true that anyone could check.
You'd get all the institutional protections of the current system. But you could minimise confusing/invalid ballot entries, and get a decisive election result for media purposes on the day of the election.
Alternatively, if you want something that's always there, you could put it on the side.
One of the seldom talked about problems with floating headers/footers is that they break page up/down. Hitting space bar now takes you slightly too far to keep reading uninterrupted.
As a beginner, you won't be building anything big, probably.
Focus on learning the stack, the language, MVC. Get to know the libraries. When you are comfortable with that, learn how to test.
Now, I believe 100% test coverage is plain silly. There are things you don't really have to test, and you are the only one who can tell.
I just started building a new app, and haven't done any testing until I was half-way through the first iteration (what I considered to be my first public alpha). I wrote a few tests to make sure the functionality I'd implemented would still work when I changed the code, then I moved to a more TDD dev style.
I wrote a few (maybe 10) tests for things I wasn't sure how they'd behave, noticed I could fix some of my code.
So, TDD can help you, for sure. But don't get too caught up in writing tests if it's getting in the way of actually writing your code.
>Now, I believe 100% test coverage is plain silly.
Agreed with this for sure. It makes maintaining tests unsustainable and time consuming to write. Cover your bases cases and make sure that important failure cases are covered. Don't try cover every possible iteration under the sun. I find that well written tests should almost read like executable documentation.
Also, I like to add a test for something every time someone reports a bug, to make sure there are no regressions (specially if it's a security problem). It also helps reproducing the bug and documenting it.
Great. Thanks for this. I am still trying to understand the intricacies of MVC architecture if that gives you any indication of my experience. I am a front end guy and have worked in the Views layer a good bit but this will be my first real language (Ruby) and framework. I felt like I was trying to cram too much in all at once. I think I will definitely wait to learn more about testing.
HTML, CSS and a little bit of Javascript/jQuery... I'm self taught, just finished an internship in front end dev at livinsocial, but want to get down to the real stuff, you know. But I'll take your advice I think and learn a little more about Ruby before continuing with all these Rails tutorials and what not.
