Lagrosh

At some point I should probably update my CV. I think it's about 5 years old now. It's strange because I think now you mostly just update your linkedin account & then people use that now (in tech industry at least).

We have such things as the `Lawyer` to get the T&Cs. and the `LegalShitController` for handling it's presentation to the user.

In fairness it's called that or some slight change on it in almost every language except English. Still fail though.

With Jira we never use the priorities. The order in the backlog is the priority. Anyone in the company can add a task to the backlog, but the multiple upcoming sprints are groomed & prioritised in order by the PM, so we never need stupid priority tag things, because inherently the only way you can prioritise is in reference to other stories.

Yeah. Jodatime is the answer for that. Another common problem seems to be people mixing presentation date logic with business logic. ISO timestamps with some date formatters based on locale is the best answer for that stuff. Seen so many simple mistakes.

Yes. But you cannot use it to do a public beta. And you can't just use it to distribute your app to some client through your website.

Got the iPhone6 & iPhone6 Plus today. The 6 is noticeably bigger, will take me a while to get used to. The 6 Plus is absolutely massive. I see how women are more of a target than men (they put it in a bag instead of breaking their trouser pockets), but I find it hard to believe there's a huge market for that (Note is the same size and has a small portion of overall market).

On iOS you need to have a dev license. Don't use the enterprise license for anything other than betas. Apple make it very clear it's not for building a distribution network.

Basically all tablets are terrible for doing most jobs. The Surface is probably the best bet for continuity. It at least will work similar to Windows 8 on the desktop and have the same apps (and sync between). Honestly, your best bet is still usually a pen and paper for the lectures, and a laptop in your bag.

We used to have those Hermann Miller ones at my last company. Really nice but quite expensive. Actually ikea do a copy for relatively cheap (couple of hundred) which are also perfectly fine.

Todd, just FYI. I pointed Claire in your direction. Very good mobile recruiter and friend of mine. Hopefully she can help you get something (and bonus points if she brings you to Berlin!)

Portugal seem to only know how to move on in the last second. Qualifying and then that. Although I think they just eliminated each other.

Yes. It's for efficiency. I've had some issues with this before when checking equality of Integer instead of int and using pointer comparisons instead of equality checks. In the tests it was fine as all values were within the range but in real life things screwed up. That was one long debugging session.

What I'd suggest is that you give them the task and ask them to solve it before they come in. That will allow them to try and solve it without the fear of someone watching your every move.

That was an amazing read. Thanks.

I love that post. In my experience it is 100% accurate.

I find when recruiters ask what I'm on it's because they're also mostly asking 'Are you any good?'. Usually when I go through a CV or LinkedIn profile I can make some sort of estimation but only the best recruiters can. I know several great recruiters for Germany, but none for London, sorry. Get yourselves 1 year of great experience working on something and then I'll get you in here.

This will always be niche though, given that the whole market is run by the carriers, and they have no control over this kind of eco-system.

I've been watching this project: https://phonebloks.com/en/goals for a while now. It'll take a long time before it gets there, but it's clearly a good idea.

I made a helpful flowchart on the Mockery. It's incredibly basic and yet most seem to fail at this: https://www.lucidchart.com/documents/embeddedchart/48ae-7f48-530a88e4-9c91-7ea90a005bed

As I use JetBrains products for basically everything, it's pretty easy to do. Create an interface file (ObjC/C++), or just the method names (Java/Ruby/etc.) and then create the test file. The tools will auto-complete a method for returning nil, or 0, or false, or Unit (void) or whatever. But whatever you do, don't create methods because you think they may be needed and then test them, or creating the code and then make a method public to test it. Only test the public methods, and only make public the methods that should be public.

So as for where to start, I advise pairing + TDD. This will help you learn. Not sure how easy this will be for you. Like I said before, try to build a project, just a Java project. With one interface containing methods like `- List<Shout> getShouts();` After you've done this, and tested it, start building the frontend Android app.

Well the idea of the 'Rockstar programmer' is pretty silly, and there are many right ways to do things. However, I would say there are also many wrong ways to do things. Mostly, however, the aspect of pragmatism comes into play. Can you have a scalable Rails app with tons of developers and lots of code in controllers/models? What about without any testing? No. But what if it's just 2-3 developers working on it and it has low scale? Sure. That's possible. Another thing is the nature of churn vs. complexity. If a file has horrendous complexity, noone understands it, and it's a total mess, it doesn't matter if noone ever touches it. On the other hand, a class which is pretty good, but not really amazing, that gets changed daily, is probably worth tidying.

I'm afraid I won't be able to go this year. Saving up for a big move amongst other things, and it's going to coincide with a launch so I'll have to miss out this year. Sorry guys.

I would suggest you hit the nail on the head here with the last sentence. If I was you, I'd concentrate on building first a simple Api layer (in a separate repo with nothing to do with Android). Use whatever networking tool you wish (in Java though I would suggest), and get it all working. Build some tests first (copying a random example from the api per call into a file for use when testing your GSON parsing objects), and then from there using a networking library to help get you some simple synchronous call when given any url & parser needed. Then build a set of request objects to help you, such as a factory for creating the request handler, parser, url, etc. needed. Perhaps called 'ShoutsCallFactory' or some such? and test that. When you have such a set of request objects that when called will go away and retrieve the data, parse it, and return it as api model objects, build a ServiceLayer. This layer will be able to take whatever parameters your presentation layer gives it (such as a method -getShouts) and handles the asynchronous requirement of your app. Here I would use RxJava, as it will solve this by returning a well-known callback interface that your Activity/Fragment can make use of, but feel free to go with AsyncTasks or whatever other tool you want in order to produce callbacks and avoid leaking contexts. Depending upon your solution for this layer, you may have to put it into an Android project (AsyncTask) or keep it in your domain level (RxJava). Then you should be able to build an Android-specific view layer on top of this. This way will also lead you to having built an SDK with which any others could also extend and modify as they wish (as well as use on another platform, such as a Java/JRuby/Scala web service).