Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

I agree with the "know your programming idioms" advice. As part of that, I wish more novices boned up their skills on unit testing and simple design principles. At the very least, I wish they concentrated more on writing clear, expressive code.

Studying how to pick good names is not that hard but it's something you don't see many new or even relatively experienced developers caring about much. They tend to focus more on technologies and the nuts and bolts, not so much the craft of writing good software.

Study refactoring and code smells. Get better at recognizing when you have duplication and code that doesn't express its intent well. Study how to write clean code. Elegant code even.
8 hours ago
@OP, you are confusing inheriting from/extending a *class* versus implementing an *interface*.

What you call a "SuperClass" is misleadingly named because it is *not*, in fact, a class. If you look at the code carefully, you can see that it is an *interface*.

Your so-called SubClass is not a subclass of SuperClass, it is a subclass of java.lang.Object. Hence, the super() statement invokes the sole, no-argument constructor of the Object class.
8 hours ago

priyanshi bhardwaj wrote:@Campbell 
Let me explain my doubt with an example let us suppose I am having a stack with elements [90 85 45 55 25 66 78 68] now if i pop two elements say 90 and 85 and after that I want to take elements 66,78,68  (making stack behave like queue ). so how can I implement this?

Your example doesn't make sense. If you're saying that 90 and 85 are being popped as normal from the stack, then taking 66, 78, and 68 in that order is still taking them in LIFO order. All you're really doing is ignoring 45, 55, and 25. Or did you mean to say you want to get back 68, 78, then 66 after you got 90 and 85?

This seems like a very arbitrary requirement. It doesn't fit with the precise functioning of either stacks or queues. I don't know why you'd even want to use these data structures in the first place if you have such an arbitrary access requirement. If anything, you should probably use a data structure that you can access randomly, like an array or even a List.
14 hours ago
As a thought exercise, it's not that difficult. You just have to think outside (or inside, as the case may be) the box a little bit. And you have to make some assumptions.

Imagine you have a stack with items already in it. The items will be taken from that stack in LIFO order. What you're saying is that you want to be able to get those items back in FIFO order. Well, that's easy. I just put the stack in a box, say some magic words, pull a stack out of the box and viola, it now gives me back all the items in FIFO order!

Now, if you're wondering what happened to the stack inside the box, here's the magician's secret: You actually have another stack inside the box. As the magician is saying the "magic words" the original stack contents are being popped and then immediately pushed into the other stack. When the magician reaches back in the box, he pulls out the newly filled stack (the original one is now empty and remains in the box), which now of course has the order of the elements reversed. To everyone outside the box, the elements are now being taken off the new stack in FIFO order relative to how they were arranged in the original stack. They are still, however, being taken off in LIFO order from the new stack.

Not sure what the practical applications for this are though, except maybe to impress a stupid interviewer.
15 hours ago

Tim Holloway wrote: the best way to think of dependency injection (Inversion of Control, or IoC)

It should be noted that Dependency Injection Inversion and Inversion of Control are NOT the same thing. They are related but two different things.

Edit: sorry, I was thinking of the principles of DIP vs. IoC

Martin Fowler wrote a fairly comprehensive article about DI/IoC here: https://martinfowler.com/articles/injection.html
15 hours ago
Thanks also to author Karl Beecher for hanging out with us this week and answering questions about the book. Surely, we didn't find your company these past few days here unenjoyable and uninformative. We hope you won't not come back here once in a while and share other bad programming practices with our ranchers
18 hours ago
Gain more experience in general. More specifically, gain experience in specialized areas like big data and analytics, security, UX (user experience), cloud, to name just a few. Having more specialized skills that are in high demand but low in supply will give potential employers better chance of being able to justify a visa for you to come to the US for employment. Otherwise, especially with the current political situation, it will be difficult to justify bringing in someone with little work experience and no specialized skills who will potentially take a job away from a similarly qualified American citizen.

Good luck.
19 hours ago
Dependency Injection basically separates the two concerns of creating and using. This results in code that is more loosely coupled, which is a good thing. Loose coupling leads to more testable code. More testable code tends to be tested more and therefore is likely to have fewer problems.
19 hours ago
Congratulations to the winners!

Don't forget to read this book with your thinking caps turned around backwards though.  (or should that be instead?)
19 hours ago

Satyaprakash Joshii wrote:For every sprint the pattern is such that we are asked to add more user stories then we estimate for and at the end of sprint in reports whatever is not completed comes in Red.I want to know that if  this keeps repeating for many months what would be the result of this?

If I were in that situation, the immediate result would be me polishing up my resume and getting the heck out of there as soon as I can. If I had money socked away so that I could survive until my next job came along, I would be out the door immediately.

If you are unfortunately unable to extricate yourself from a toxic environment like that, the result would be declining morale in the development team, declining productivity, increasing number of bugs, more pressure from management to get things done, and an ever increasing downward spiral into the pits of hell. That's what you have to look forward to in the next few months unless somebody stands up and says "Enough of this madness! This isn't what Agile is supposed to be!"
1 day ago
Late to the party but what OP describes is exactly why Agile these days isn't what it was intended to be and enthusiasm for it is dying in many places (some even consider it to be Dead already). No matter what you choose to call it, I certainly wouldn't call it "Agile", that way of working is just not what the originators of the Manifesto envisioned. That's what they were trying to get away from.
1 day ago
I have had a bit of time to catch up on my reading list so here's a word cloud that's kind of floating around in my head right now:

communication Collaboration Working Software building the right thing Outcomes vs Output
testing experimentation data Design Thinking #noProjects Teams #noEstimates

I don't know why but Josh's idea seems to fit in there somewhere.

Edit: Maybe because #noPO? And Chartering?

Joshua Kerievsky wrote:... you have replaced product owners with communities that collectively own the work

Jeanne Boyarsky wrote:Making all decisions by committee feels incredibly time consuming given the number of competing demands we have.

I think there's an important distinction between committee and community. I think having a charter that everyone involved buys into is a key differentiator.