|
David O'Neil wrote: I am missing something - tell me I am missing something! It can't be that restrictive!
Mobile Safari does this thing where scrolling down will hide the address bar and bottom toolbar to make the website feel more like an application. Which seems like a great idea, and stuff should reappear when you scroll up. Buuttt, I have seen it get stuck on occasion. Not sure what triggers that.
To me though, that's just a bug (dear God I hope so) and not intentionally designed to be stuck. My point was more about Apple losing its elegance on the things it intended to do. Assuming that getting stuck wasn't a design feature.  But yeah, it's whack to have that happen.
David O'Neil wrote: Even worse, tested it by pausing the video then hitting the home button. Going back to Safari, the video wasn't up! It went to default, or something. I've never had that happen with my phone browser.
Yeah when it gets stuck, you either gotta scroll like a wild man and pray or just close Safari out. The Home button won't do it, that's akin to minimizing the app while its still running.
David O'Neil wrote: Every time I've played with Apple stuff I end up shaking my head in wonderment of their non-intuitiveness - like the time I played on a Mac and didn't know the trick to two-finger scrolling. Couldn't use the mouse to grab the scrollbar, so couldn't even scroll a web page intuitively.
As far as the two finger scrolling on a trackpad, that's an industry thing. It's the same exact way on a PC laptop. Not like Windows advertises that either. So let's at least play fair... you hate two finger scrolling.
About the mouse scrolling, the PC world never gets really creative, so my guess you're thinking like a PC user. A typical PC user acts like the world is about to end if Microsoft changes one icon. Apple is nothing of the sort. They will try new things and innovate. Microsoft does not innovate; they copy. And so they will eventually copy Apple once things become accepted or not after Apple gives it a go. It's always been that way (except for AR), and scrolling is no different. So, if you don't like change Macs aren't for you.
Anyway, about scrolling... Macs attempt to aim for elegance. Well, they used to. So you may wanna watch a tutorial on how to scroll. There are scrollbars, but they also hide if not needed (can be set to always show) and the mouse itself acts as a scroll wheel. Check the video out, man.
Edit: Keep in mind, I don't like having to use my thumb at all for shortcuts on a Mac. I'm a pinky dude through and through. So, Macs aren't perfect. Just want to make sure, we're playing fair here.
Jeremy Falcon
modified 9-Apr-24 22:08pm.
|
|
|
|
|
Jeremy Falcon wrote: So let's at least play fair... you hate two finger scrolling.
To be fair, it wasn't even about two-finger scrolling. I had only been exposed to it on crappy Windows laptop pads, and it never worked right. I didn't expect two-finger scrolling to be incorporated into the mouse itself, so wasn't expecting that to be THE ONLY WAY to scroll. What the real issue was is that I could not get Safari to scroll up and down even using the intuitive way: getting the scroll bar to appear, clicking on it with the mouse, and dragging, or clicking above/below the scrollbar. I believe I even tried page up/down, and didn't get that to work either, but I'm not sure about that - it was a while ago.
When I finally found out how two-finger scrolling works on Macs I kinda liked it. But figuring that out when I'd heard and seen that Apple only uses one-button mice? It just wasn't an intuitive jump. Everyone (said?) Apples are intuitive. I don't buy that any more. If you buy an Apple product without any background in the ecosystem you will probably need a friend to get you started, or videos, like you said.
|
|
|
|
|
David O'Neil wrote: . I didn't expect two-finger scrolling to be incorporated into the mouse itself, so wasn't expecting that to be THE ONLY WAY to scroll.
It's one finger scrolling on a mouse and two finger on a trackpad. And just a heads up dude... don't shout. Like, you really that emotional right now? If that's trying to be funny it ain't.
You're forgetting something, Macs integrate software and hardware. You should know this. Also, you didn't watch the video link otherwise you'd see the error in your statement. Come on man, do better.
Jeremy Falcon
|
|
|
|
|
Chill! Your skin is thin today! Have a better one! 
|
|
|
|
|
I'm a firm believer their decline started with the corporate charter.
Growth is only good when it's not cancer.
|
|
|
|
|
I was watching a commentary video (Scams In Software Engineering[^]) by Primeagen (funny youtuber who really understands dev and comments on development ideas).
While watching that video he mentions:
“The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.”
The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code
This is actually something I have been interested in for a long time and why I wrote a recent article here on CP: Is Dependency Injection the Missing Technique That's Holding Your Career Back? [^]
In that article I discuss how that DI causes a redirection of code (lack of Locality Of Behavior) so bad that DI can be quite terrible.
Two Issues
1) Seeing a call to a method DoThatThing(), only to discover that the implementation is in an injected class that is in another assembly and then you have to jump into that assembly to even see what it is doing, is a terrible part about DI.
2) Added on top of that, you have to know how all of the associated classes work to understand how the small piece of code works.
EDIT
Also, this idea of getting Locality of Behavior could be a naive one also. Meaning that only simple problems can have simple code and advanced coding for larger systems may require more obscurity in the code due to necessity of DI, patterns etc.
What do you think?
modified 9-Apr-24 10:17am.
|
|
|
|
|
Larger systems won't demonstrate locality of behavior because of frameworks that use polymorphism and inheritance to invoke application classes. That's not much of a problem because people working on the system will be familiar with its frameworks, so all they'll usually need to look at are application classes. If the frameworks are well designed, all the code for an individual application will be colocated, making it possible to understand that application even though its implementation is scattered among various colocated classes.
When the DoThatThing in your DI example resolves to a specific target without the use of polymorphism or inheritance, I never got the point. It seems like artificial complexity and needless boilerplate.
|
|
|
|
|
Greg Utas wrote: That's not much of a problem because people working on the system will be familiar with its frameworks
But this can be a "training issue" and even more so depending upon how many "company-specific" patterns are used.
This, in turn, means that you're always slower on maintenance and enhancements because "we always have to train new devs in our patterns so they can even fix one simple bug.
Greg Utas wrote: If the frameworks are well designed
Emphasis on if... 
(Yes, I'm being a bit facetious.)
You make good points but man code is just so often terribly obfuscated -- and especially so when DI is involved. That was my point of DoThatThing: no you can't just see the implementation here, you have to jump into another class then another one that is in another assembly and
You have to have the Gestalt of the entire system in your head before you can do one simple thing.
|
|
|
|
|
The training issue can't be avoided with new devs. If you don't have frameworks, you'll have spaghetti, which will be even worse. Nested function traces are a great way to help new devs navigate the code.
|
|
|
|
|
That's why I don't necessarily agree with the idea that having it spread out across classes in the same solution is "just fine" not at all deserving of a tiny bit of a spaghetti moniker.
You get two levels of indirection with some patterns. These patterns deliver... things (CQRS/event sourcing), but imo, you should probably have a significant team size with many juniors to get ROI on it.
Lately, I don't think many want to hire junior/entry. They want to hire people for whom this sort of thing will just ultimately be ball and chain.
I think the thing with this is that it is mostly minor annoyance for more avg-to-senior devs but from the bottom to a bit above avg it is holding them back probably far more than it is protecting our codebases. Have reviews and teach people. This sadomasochistic forcing of pain by pattern in the name of quality that still won't be there is a bit nonsense.
Teach what makes quality if you want quality, don't teach that pain makes gain. It doesn't and it's impossible from the perspective of students' in this scenario to grok the difference. If they could, it would have less value to do it. To me, it feels a whole lot like slews of this stuff are thinly veiled gatekeeping aimed at increasing complexity to maintain superiority by tumbling trashcans as the elite flee the scene. But I might be a bit of a cynic.
|
|
|
|
|
Thanks for posting. So many great things in your post. 
jochance wrote: not at all deserving of a tiny bit of a spaghetti moniker.
That's exactly right! Software "Engineers" are often ready to cast aspersions upon code that "isn't following an exact pattern" by saying it is spaghetti. I'm not talking about bad code with no structure at all. I'm talking about the fact that often patterns are over-wrought & forced into a solution with little to no benefit, except that they're considered "pretty" to software "egineers".
jochance wrote: They want to hire people for whom this sort of thing will just ultimately be ball and chain.
Very true.
jochance wrote: This sadomasochistic forcing of pain by pattern in the name of quality that still won't be there is a bit nonsense.
Exactly! MOst of the problems still exist -- they just exist at a different level.
You're still going to have issues doing maintenance and enhancements. (again, I'm not talking about completely unstructured code with globals everywhere, etc.)
jochance wrote: To me, it feels a whole lot like slews of this stuff are thinly veiled gatekeeping aimed at increasing complexity to maintain superiority by tumbling trashcans as the elite flee the scene.
I agree. It has a feel of making sure that Software Engineers can create a wall between them and the minions and almost is a form of virtue signaling in Software Design. "Oh, I use the Strategy pattern with a Decorator here." Ok. ok, software "engineer", you've hit me over the head with it. 
And, yes I believe in patterns, DI, designing toward interfaces, etc. But I believe in it when it has a specific purpose.
|
|
|
|
|
I think you're taking "locality of behaviour" a little too literal.
It's not like all code has to be in a single method or something like that.
Quite the contrary.
Let's say we have a function that fetches an entity from some service, inserts that entity into the database and then returns the ID.
Now, if everything was "local" you'd create an HttpClient, do the fetching, then establish a database connection and do the insert while returning the ID.
You now have to look at one function to understand what it does and to change the behaviour (for example, add a property).
However, you've also coupled your service to your database.
One can't exist without the other.
I probably don't have to explain it would make a lot more sense to create a class that deals with the service and a class that deals with the database insert.
Your function could now look something like:
var something = service.Fetch();
return repository.Insert(something); That's a gross oversimplification, but you get the gist.
In this example, service and repository are probably injected.
Now you could argue that you don't understand what this code does anymore, but I'd say that's not true.
You still understand the code, it's just that its internals are hidden from you so you don't know how it does it.
Now, let's say a property is added to the service and you also need to store it in the database.
This is where the true locality comes into play.
Because both changes are local to their respective function.
So the service change is a different one from your database change because they're now isolated units of code.
They could be implemented by different teams, the service change could already be implemented while waiting for the database team to add a new column to a table.
And now other parts of the code can also use service.Fetch and repository.Insert in the same way.
Yes, you'll still need to figure out what type of service and repository is (probably some instance of IService and IRepository), but that should be easier than maintaining a long function that does multiple things.
Now how would this code not be "local"?
Let's say the implementation of service.Fetch would do something like "&type=CUST" and then in your repository.Insert you also do a check on "CUST", or some other check that has to do with the internals of service.Fetch.
You'll now always have to change two functions that seem isolated, but really aren't (and you have to know this or you'll break the code!).
Or when service.Fetch does the call to repository.Insert, because you'd think you can fetch, but it's now still coupled to a specific database action.
So in conclusion, don't think of "locality of code" as "code has to be local", but "code has to be as local as possible", which is not the same 
The author mentions it too, saying it's often a trade-off 
|
|
|
|
|
Sander Rossel wrote: I think you're taking "locality of behaviour" a little too literal.
Yes, I was thinking that all code should just be in one file. I think you were taking what I said too literal.
No, I'm just experiencing code where there are Interfaces for every class in the system.
Have you ever looked at code where there is literally an Interface for everything?
Sander Rossel wrote: don't think of "locality of code" as "code has to be local", but "code has to be as local as possible", which is not the same
The author mentions it too, saying it's often a trade-off
Yep, balance. That's what I'm looking for.
However, much code is often extreme one way or the other and I'd often heard of reasons to break code apart, use patterns, design to Interfaces,
but never heard Locality of Behavior mentioned.
Which seemed unbalanced.
modified 10-Apr-24 9:06am.
|
|
|
|
|
raddevus wrote: how that DI causes a redirection of code (lack of Locality Of Behavior) so bad that DI can be quite terrible.
But wait - then the code won't be cool!
|
|
|
|
|
Question: Why did you join the network?
Original in german: Quote: Weil ich nicht einverstanden bin, wie manche Sachen laufen und, für mich, die beste Art etwas zu verbessern ist, ärmeln hochzukrempeln und aktiv anzupacken
I would say:
Because I didn't like how things are being done and, for me, the best way to improve something is, to roll up one's sleeves and actively ...
tackle it // seize it // go for it // something else?
Improvements about the whole sentence are welcome.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
..., die Ärmel hochzukrempeln und [Dinge] aktiv anzupacken
..., to roll up your sleeves and actively tackle [things]
|
|
|
|
|
Thanks
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
These sentences have the same gist.
1. I believe in taking a hands-on approach to improve things when I see they're not going in the right direction.
2. When things aren't going well, I prefer to dive in and make a difference.
|
|
|
|
|
Thank you
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Some more ideas come to mind.
1. Getting my hands dirty (an idiom a native speaker might use)
2. Take charge.
|
|
|
|
|
#1 is something we say literally translated in spanish.
#2 is not exactly what I want to mean. Because I can't take charge of many things since it is a big company.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
So relaxen und watchen das Blinkenlichten!
|
|
|
|
|
Almost...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: something else
(for me to) take complete ownership.
|
|
|
|
|
Not exactly what I mean.
In own actions yeah. The context (I didn't explained it correctly before) is corporate. There is a network created by one of the chairmans about culture@work and professional change of mind.
I am part of it and I do what I can as a speaker, moderator of groups helping other departments to improve processes, showing there are other ways of doing things and things like that...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
