Ombu Labs (https://www.ombulabs.com) | Software Engineer | Philadelphia, PA; Buenos Aires (ARG); or REMOTE | Full Time
Ombu Labs, The Lean Software Boutique, is hiring a full-stack software engineer to work on our products and consulting projects.
What we do: We aim to write less software. We take YAGNI to the next level. We apply lean principles to our own products and our client's products.
Why us: You will be our 4th software engineer hire. We are a small/agile company passionate about open source, pair programming, Ruby/Rails, and continuous improvement.
I'm still trying to find Mercado Pago's Security section and security vulnerability protocol (e.g. Who do I contact when I find the next security hole?)
Just because they're not doing it like Stripe doesn't mean they're rookies, they also did $7.1 billion in transactions last year. Most companies have pretty obscure/lacklustre security outreach, it's something that's getting a lot more emphasis these days than it used to.
Just because they did $7.1 billion in transactions last year, it doesn't mean they're not rookies.
Most of the big IT companies in this side of the world follow the ideology of "we don't care about doing things correctly, we only care about getting the stuff done" and succeed because of the traction they generate due to the lack of serious competition.
Recently Amazon joined the e-commerce arena in Mexico, but my expectations are that Mercado Libre will follow the footsteps of Ask.com, Source Forge, etc. instead of improving, they have been arbitrarily doing UX anti patterns in the last years in order to protect their income at the expense of the users.
The fact that they allowed such a blatant vulnerability to reach production makes me question their test suite and development process. What else is wrong that we are not seeing?
I expect more transparency and professionalism from a company that processes $7.1 billion in transactions.
It's not unreasonable to expect better transparency, that's something that's improving too slowly. We don't even know if this was exploited yet and it's been a couple months and there's always a lot of opacity around hacking incidents.
Security is hard and accidents are easy, dropbox once had a four hour period where they didn't verify passwords!
That is pretty embarrassing too and even a bigger vulnerability, but Dropbox released a statement about it.
I believe that owning up to your mistake and being transparent about it can only make your customers trust you more. What worries me is that Mercado Pago is huge and they never released a statement about this issue. I hope that they change this policy soon.
Using their authentication mechanism, a user should only get an access token with the right combination of client id and client secret.
For at least 7 hours, anyone could get an access token for any client id, without entering the right client secret. With that access token they could see a lot of information for any account.
If I go to my stakeholders and customers with Spec or Unit code, and ask them: "Does this test represent your idea of how this feature should work" I'll get no useful answers.
I can read it to them, or we could collaborate on a user story that doesn't get directly mapped to tests, but then we have room for the interpretation/translation process to create the wrong assumptions in the test code.
There are plenty of tests I'd never show the customer because they involve implementation details, and those aren't going to be written in Gherkin because I don't hate myself enough to juggle that many regexps.
> But that one advantage doesn't really matter that much when everybody in your project knows Ruby
Well, yeah, if people who aren't Ruby coders aren't reading your tests, Cucumber is overboard: the motivating use case for Cucumber is acceptance tests where the main part of the test (the part that isn't implemented in Ruby code) is owned by and validated by the customer/user, who presumably isn't generally, except by coincidence, a Ruby coder.
It might also be useful for integration tests where that need to be validated by people familiar with the overall system design/architecture, but not necessarily the language that any particular components are implemented in, for the same reason.
There is some value in using it when everyone knows Ruby: it forces you to get your head out of the code, using language that your customers understand rather than naturally defaulting to codespeak.
I use Cucumber on my own projects when it's just me, for precisely this reason.
I really like Google's paper on technical debt: https://ieeexplore.ieee.org/document/10109339
I wrote an article with a summary of the key insights in that paper: https://www.ombulabs.com/blog/tech-debt-maturity-model.html
Hopefully, the more articles like this one, the more non-technical managers will finally give a shit about technical debt?