The question I have about this: Does making it easy to do parent?.child?.grandchild?.property help or hinder the software development process in the long term?
This will help getting rid of the Maybe monad pattern in our code (at least partially) - all patterns are patches for missing language features. I cannot see any drawbacks personally. Would much rather prefer the 'object! paramName' not-null enforcement operator though, but it is tricky to make it backwards-compatible.
The ?. has only really worked in scripting, i.e. writing quick scripts to manipulate code written in a proper type-checked programming language. Groovy has it but Java doesn't. In Groovy's heyday if some code spewed out NullPointerException, the first thing people did was replace all the . with ?. and run it again, because the code was throwable quality anyway. I can't imagine anything good will come of putting ?. into C# (or Java) which is meant for building more lasting systems.
instead of putting a null check between every call. In many cases null is used to indicate that a computation failed. If you are doing a chain of computations, there is often not a reason you need or want to do a check between every computation, instead of having a single handler at the end for if any of them fail.
This pattern comes up fairly often in Haskell, which accomplishes it with the Maybe monad.
There are certain languages and situations where the pattern does make sense. But as a heavy C# coder, I find that more often than not you're dealing with a class heavy codebase where it's more important that you _don'_ do foo()?.bar?.bing(). Specifically as things happen such as refactoring you often need to ask the question should something 'care' that a foo has a bar which has a bing. Perhaps if you want to know about a bing that is down the chain from Foo, perhaps Foo should provide you with the Bing somehow (which really helps with refactoring as codebases grow to years and potentially decades old).
It's not always so cut and dry, and there are situations where this is a very valuable tool. I just feel that down the road if you feel like there is a valid reason for refactoring object hierarchy that you'll potentially be doing yourself (or those that follow) a disservice in the long run.
Yes, you could do that, but it goes against how everybody has been accessing object properties for the past two decades.
Quite often, you simply want person.address.street.number, and if it doesn't exist, you simply go on without it, and it doesn't matter what the exact reason is why it doesn't exist.
This is an extremely common and practical pattern, and it's hindered by layers of null pointer checks.
Groovy is used for very serious websites, just like Java. And in Java, maintainability, and therefore readability, of code is just as important as in Groovy. I really like the ?. operator, and I miss it in Java. It makes code cleaner, more robust, and easier to check. Less boilerplate, more readability.
I can understand the reason for it being there, but I also tend to fall towards following the Law of Demeter. I tend to find that most (not all) of the use cases of this are a symptom of overly intimate knowledge between objects that really shouldn't know about one another.
I will start by saying that the sentiment of this is simple and true. The value added by the "Unlock All" button in it's simplicity is valid.
But they didn't "just add a button" they also added over 3x the content to give that button value.
If they had kept their original 3 books and added the button I'm guessing they would have seen next to no difference in the bottom line.
My point being that in order for an Unlock/Buy All button to work, you need to have enough content/product/etc to make the button worthwhile. Just adding a button may not be enough.
But my question is, what if the app doesn't, and isn't ever meant to, support a large number of users? What if even with the concurrency issues, it's fast enough?
Thanks for the feedback. One of the projects that our front-end engineer is currently working on should fix this issue, though it may not be live for a few days. Very sorry for the inconvenience.
I have to agree. Two things have happened here to make me see it:
- Taking on a role with more responsibility, leadership requirements and business knowledge
- Starting my own business where I get to make decisions (with my co-founder)
I see how many times as as developer I've either not cared about decisions that directly affect me. Or maybe I've just rolled over and accepted the things I don't like. It's the nature of (most) developers. Don't stir the pot. Don't dissent. Just get in and get my work done.
Here's the reality. Knowing more about your business makes you a better developer. Knowing how to say no and stand up for yourself makes you a better developer. Knowing how to talk and communicate with your users, your bosses, your co-workers (or anyone really), makes you a better developer (and will improve your work life). Being a strong technical person with strong Business, Marketing or Personal Communication skills makes you unstoppable. This applies to more than technical folk. The more you do - The better you are. Take this advice you might find that the skill you thought you were bad at, or hated, or avoided is actually very rewarding - Difficult, but rewarding.
And finally, to Amy: Thank you for all the work you do on showing people the power that they have. I started a business 5 years ago and have had to sit through the whole "YOU NEED TO GET FUNDED" and "YOU NEED TO GET BOUGHT" that seems so prevalent in the startup ecosystem. Me and my partner did everything ourselves. And now we own a business that makes decent money that goes DIRECTLY TO US.
But when you're overexposed to the opposite line of thinking, it's really easy to get caught up in the "am I doing this wrong?" and questioning yourself. You are one of the few people who puts an emphasis on growing and trusting YOURSELF. I'm very on board with most the things I hear you say because they are the very values that I have held in high esteem, yet was still questioning. So thank you for that.
ps. I also think that 'ahoythere' would've been an awesome username.
"I see how many times as as developer I've either not cared about decisions that directly affect me. Or maybe I've just rolled over and accepted the things I don't like. It's the nature of (most) developers. Don't stir the pot. Don't dissent. Just get in and get my work done."
Exactly. If you live with the attitude of a cog, you'll be treated (and paid!) like a cog. You get what you ask for.
And, thanks for the "thanks." You're welcome. It's always nice to hear that I'm not just pissing into the wind.
He's basically a step away from having several objects (let's call them handlers) which can do your handling for you. Further, they can define the set of circumstances in which they are valid.
I'm going to work with a couple of assumptions:
1) The test casts which he refactors to test*() methods are non-trivial
2) The handlers _may_ be large sets of code
Here's a way to handle one of this refactored methods:
if (!test1()) {
handle_failure_1();
return false;
}
if (!test2()) {
handle_failure_2();
return false;
}
if (!test3()) {
handle_failure_3();
return false;
}
handle_success();
return true;
That's a lot of potential code we're dealing with in this class.
What if:
class HandlesFailure1
def handles_this_case(params)
#code from test1()
end
def handle(params)
#code from handle_failure_1()
return false;
end
end
class HandlesFailure2
def handles_this_case(params)
#code from test2()
end
def handle(params)
#code from handle_failure_2()
return false;
end
end
class HandlesFailure3
def handles_this_case(params)
#code from test3()
end
def handle(params)
#code from handle_failure_3()
return false;
end
end
class HandlesSuccess
def handles_this_case(params)
return true
end
def handles(params)
//code from handle_success
return true
end
end
#And now the original class
class DoesSomething
#There are ways to set this up fairly easily. One simple way it to just new it up here, but you could auto-wire it too
handlers = [HandlesFailure1, HandlesFailure2, HandlesFailure3, HandlesSuccess]
def do_something(params)
handlers.each do |handler|
return handler.handle(params) if handler.handles_this_case(params)
end
end
end
There. Now there's a loop and an if. Check each case and either handle or toss it out. This can also work for the case where you might want multiple handlers to handle something, just don't return on the first one.
I'm not saying it's the right way, but it's another way.
Pros:
It really helps to group together the handling methods with the test methods.
Very simple dispatch method
Cons:
Separate classes, and harder to view all the handlers together.
Children's minds are built to soak in information. You could wait until a kid was 10 to introduce them to computers and they would still blow your mind with what they could figure out and do.
I highly doubt that holding off on video games and computers will be a detriment in the long run.
I spent nearly a year building a SaaS application for Oil and Gas companies here in Calgary. My partner had the idea after he got tired of phoning/emailing/talking to every contact in his book in order to find partners/buyers in land deals.
So after a year of weekends and evenings, my partner started to pound the pavement. We were profitable in our very first year after launch, and continue to be. Our biggest expense is advertising, which is very targeted. I think about 80-85% of our pre-tax revenue ends up being profit, which is great.
I still have my day job, and for the 30 hours/week between us that we still put in, we've been _very_ successful.
