Stuie Clarky

Ranch Hand
+ Follow
since Nov 09, 2012
Stuie likes ...
Eclipse IDE Java Ubuntu
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
15
Received in last 30 days
0
Total given
7
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stuie Clarky

Hi Joel,

In your opinion, what is the biggest sin that developers commit in their apps that are released on the Play store (without naming names etc)?

In my limited development experience (although a long time Android user) it is when apps get successful and the developers start to shoe-horn in as much content as possible. This tends to result in both feature and permission bloat, which for me spoils the user experience as performance usually suffers as a result.

Best of luck with the new book

Cheers,
Stuie
2 years ago
Hi Joel,

Welcome to the Ranch, and congratulations on your book
2 years ago
Whilst I don't know about the specifics of getting a job in Mumbai, I can tell you the OCAJP exam is the first one you will need to do. Once you have passed this, you can then do the OCPJP exam. If you already have a certification from an older version of the exam, then there is the upgrade exam you can take instead of either of these two.
Book received, will be making the time to get stuck into this.

Thanks again
You could test it yourself - copy the jar over to a different machine and see if it works. You will want to do that sort of testing before you go in front of a client
2 years ago
As other posts on here say, leave the IDE (intellij) alone to begin with and start with the basics of your favourite text editor and the command line. The trail examples here on the ranch are done using the command line if you want to look at them.

The reason this advice is given is an IDE, while a powerful tool, will highlight errors and offer suggestions to fix them without you even realising what you've got wrong on the first place. Starting with the text editor will help enforce the basics of syntax, and how to read the error messages from the compiler and understand exactly what it is telling you.

As for books, head first and learning Java are both good, as is the Detil and Detil book (although it's not cheap)
2 years ago
Oh wow, thanks. Additionally, thank you to the authors for taking to time to respond to us, greatly appreciated
Given how much you have managed to do so far without an IDE, I'd say you have a pretty decent grounding for how things work, what various error and compiler messages mean and how to fix them, how to package and deploy things (assumption based on creating things connecting to databases). An IDE will help smooth off the rough edges, like being able to easily refactor, auto-adding imports etc for you. Its important to learn how to do things from scratch, but using an IDE will help make you more productive.

To be honest, you could still compile and build things from terminal, an reduce the IDE to basically a very fancy text editor.
2 years ago
My thanks to you all, you have given me plenty to think about and digest
Brilliant, thanks.

Will need to get my lucky negotiating hat out at some point then, to get the time allocated
My thanks to you both for your top answers.

As a theoretical question, assuming I now differentiate between architectural/code smells (something I had not really thought about before) to my stakeholders (whom we will say are a risk adverse bunch), how do you think would be a good way to approach us paying off some of the technical debt?

Granted this is probably moving away from the scope and intent of the book, but I would like to know your opinions/thoughts on how best to approach this. It seems silly to me that there are companies/ decision makers out there that would freak out if you told them the rent payment was late, but don't seem to care at all about technical debt.

Thanks again for your detailed answers, very much appreciated

Stuie
Hi guys,

My question is how does the book approach addressing technical debt, in the sense of identifying the scope of the changes required, to testing before/after the changes and ensuring what you have done is both functionally and technically correct? Working with a legacy product there are bound to be years of tweaks and fixes for obscure corner cases that may not be obvious at first glance, but you know will blow up when it reaches production.

Best of luck with the book,
Stuie
Hi to all the authors and thanks for taking the time to be here
I received my copy yesterday. Quite the weighty book.

Thanks again for my copy, and to the authors for responding to my question