Two Plus Two Publishing LLC Two Plus Two Publishing LLC
 

Go Back   Two Plus Two Poker Forums > >

Notices

Programming Discussions about computer programming

Reply
 
Thread Tools Display Modes
Old Yesterday, 03:52 PM   #30226
gaming_mouse
Carpal \'Tunnel
 
gaming_mouse's Avatar
 
Join Date: Oct 2004
Location: taking notes on u (see profile)
Posts: 13,726
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by candybar View Post
Counter-counterpoint: Google & Facebook
I don't know anything about there architectures -- are you saying they are monorepos?

Quote:
Also, 1) lots of companies are actually smaller than an Amazon team.
Sure. And there's definitely such a thing as breaking things up too early, but I assumed we were talking about larger systems. But even there, like with a medium sized web application with a SPA frontend, I'd generally prefer to have 2 repos. Because those two things are only supposed to touch through the API.

Quote:
2) monorepo does not dictate anything about the run-time architecture of your system.
technically true, but in practice it affects how people think about it. Having multiple projects in separate repos establishes boundaries in a way that's clearer and harder to ignore.
gaming_mouse is offline   Reply With Quote
Old Yesterday, 04:37 PM   #30227
candybar
old hand
 
Join Date: Aug 2011
Posts: 1,674
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by gaming_mouse View Post
I don't know anything about there architectures -- are you saying they are monorepos?
https://danluu.com/monorepo/

https://cacm.acm.org/magazines/2016/...itory/fulltext

https://code.facebook.com/posts/2186...l-at-facebook/

Quote:
Sure. And there's definitely such a thing as breaking things up too early, but I assumed we were talking about larger systems. But even there, like with a medium sized web application with a SPA frontend, I'd generally prefer to have 2 repos. Because those two things are only supposed to touch through the API.

technically true, but in practice it affects how people think about it. Having multiple projects in separate repos establishes boundaries in a way that's clearer and harder to ignore.
The problem is that project boundaries often need to change - with more than one repo, meta changes (moving stuff from one project to another) become difficult enough that people stop bothering after a while and a bad architecture gets calcified. Also, sometimes even good boundaries aren't perfect due to cross-cutting concerns and you need to make changes across a whole bunch of projects - this is much easier to do and far easier to track with a monorepo. Also, for a large engineering organization to succeed at scale, you need heroic people who are willing to do things that somehow fall through the cracks and technically don't belong to any team, to make things work. Monorepo enables these people both technologically and culturally. Having lots of repos also often leads to engineering teams not looking at one another's work, which often leads to the decline in engineering standards and proliferation of duplicative technologies and bespoke tools.

In the node world specifically, with all this babel plugins, webpack/eslint configs, not to mention conflicting versions of the same frameworks and libraries and what not, it becomes very easy for code bases in separate repos to diverge enough that, despite being merely features in a single app, you can't even move things around any more. It sort of allows developers to move faster with more control at the module level at the expense of a much higher total cost of development. None of the complexity actually goes away - all the components still need to come together and work together. Over time it also leads to legacy repos/systems that everyone depends on but no one owns or knows anything about. Monorepo keeps everything, even ugliness, in plain sight.
candybar is offline   Reply With Quote
Old Yesterday, 04:56 PM   #30228
Larry Legend
Isaiah GOAT
 
Larry Legend's Avatar
 
Join Date: Jul 2009
Location: Let's go celtics
Posts: 41,123
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Whenever I write code I think of my variable and function names as telling a story, and use naming conventions like suzzer mentioned. If it is not clear what the code does and why it does it from that, then I have failed and should re-write it.
Larry Legend is offline   Reply With Quote
Old Yesterday, 05:53 PM   #30229
jjshabado
Carpal Tunnel
 
jjshabado's Avatar
 
Join Date: Jul 2006
Posts: 21,733
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by Larry Legend View Post
If it is not clear what the code does and why it does it from that, then I have failed and should re-write it.
I'm going to admit that I'm a far from perfect programmer. Sometimes I have something that works and its easier/faster/more efficient to just slap a comment on there, ship it, and move on.

Edit: Also, the premise is only mostly true. There are times where its not possible for the code to reflect why it does something in naming. For example, when dealing with performance issues or fixing certain types of bugs.
jjshabado is offline   Reply With Quote
Old Yesterday, 05:59 PM   #30230
kerowo
lolcat
 
kerowo's Avatar
 
Join Date: Nov 2005
Posts: 33,140
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Code:
Initialize.goFaster()
goFaster(allTheThings)
kerowo is offline   Reply With Quote
Old Yesterday, 06:52 PM   #30231
jjshabado
Carpal Tunnel
 
jjshabado's Avatar
 
Join Date: Jul 2006
Posts: 21,733
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

jjshabado is offline   Reply With Quote
Old Yesterday, 07:51 PM   #30232
ChrisV
Carpal \'Tunnel
 
ChrisV's Avatar
 
Join Date: Jul 2004
Location: Adelaide, Australia
Posts: 34,354
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by Craggoo View Post
This is bs. As far as I'm concerned, anybody who says this is just trying to justify being lazy. Would you rather work in a code base that is heavily documented such that you know where you need to make your updates or your "self-documenting" code base? The non-documented code base assumes that whoever worked on it did a good job. That is a very generous assumption.
Knowing where I need to make updates (i.e. where in the codebase I need to go to accomplish something) is the job of Confluence or some other external documentation. I shouldn't be digging through comments in the actual code to figure that out.

All else being equal, I would prefer that a poorly written codebase is accurately commented. The problem is, comments are not a defense against bad programmers, in fact they frequently make matters worse. I once inherited a disaster of a codebase that had been written by a bad offshore team. While refactoring it, I deleted all comments on sight. 99% of them were either obvious or wrong or both. Frequently code had been copied from one place to another and then the code had been modified and the comments had not been. I think programmers who write shoddy code but useful and well-maintained comments are pretty rare beasts.

Quote:
Originally Posted by gaming_mouse View Post
I don't think it's that tricky, actually. If you need comments to explain what specific code is doing, the code needs to be rewritten.

Comments are appropriate for high-level concerns like explaining architecture, the reason module X was chosen, or the history behind some oddly chosen name.

As a rule of thumb, comments are the kind of thing you'd say to someone before you opened up a tex editor: "Oh, before we get into this, let me tell you X....".
Right. And that can be low level too, sometimes. For example, an explanation that something is being done a weird way because the "obvious" way to write it runs into some obscure bug.

Occasionally code will be complex enough that an explanatory note is needed, yet rewriting it a different way is not practical. An example might be a complex regular expression. Those instances should be kept to a minimum though.
ChrisV is offline   Reply With Quote
Old Yesterday, 09:15 PM   #30233
daveT
S.A.G.E. Master
 
daveT's Avatar
 
Join Date: Jun 2005
Location: Why didn't I use Clojure instead?
Posts: 21,705
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

I know I see far more bad code than good code, but I'd say a common thread among good code is it's self-documenting properties. Sadly, good and bad code feature little to no commenting, but I don't think comments would improve either good or bad codebases, and I think comments would be more detrimental than useful in bad codebases.
daveT is offline   Reply With Quote
Old Yesterday, 09:18 PM   #30234
gaming_mouse
Carpal \'Tunnel
 
gaming_mouse's Avatar
 
Join Date: Oct 2004
Location: taking notes on u (see profile)
Posts: 13,726
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Ok, I read those, and I don't know what to say. I think I don't believe it. Literally. They aren't using a monorepo. Just no.

Clearly I'd need to see the whole thing in action and maybe it would make more sense, but for now I'm going with it's a conspiracy.

Also, there's something wrong about focusing on the "repo" part. Like, no matter what you do, you break things down somehow. You can't get around it. They draw the boundaries somewhere. You don't have a mono anything that big. Not really.
gaming_mouse is offline   Reply With Quote
Old Yesterday, 09:24 PM   #30235
gaming_mouse
Carpal \'Tunnel
 
gaming_mouse's Avatar
 
Join Date: Oct 2004
Location: taking notes on u (see profile)
Posts: 13,726
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by ChrisV View Post


Right. And that can be low level too, sometimes. For example, an explanation that something is being done a weird way because the "obvious" way to write it runs into some obscure bug.
totally fine.

Quote:
Occasionally code will be complex enough that an explanatory note is needed, yet rewriting it a different way is not practical. An example might be a complex regular expression. Those instances should be kept to a minimum though.
also fine. like i said, there are exceptions. but they should remain that.
gaming_mouse is offline   Reply With Quote
Old Yesterday, 09:27 PM   #30236
candybar
old hand
 
Join Date: Aug 2011
Posts: 1,674
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

The most common good reason for commenting that I've found was when you're working around something that you can't do much about. A bug in runtime/framework/library for instance often necessitates that you write wrong-looking code - I think one time I had to write something that looks like a no-op to work around a bug in dealing with iframes in jQuery that was IE-specific. Outside of browser issues, if you deal with low-level code, it's very common to find bugs in libraries that relate to thread/exception/memory safety, which you need to write wrong-looking code to work around. While I'm perfectly fine with well-written, self-documenting code with no comments, it's a bit of fantasy to think that we can do that all the time - real software engineering isn't always pretty.
candybar is offline   Reply With Quote
Old Yesterday, 10:00 PM   #30237
candybar
old hand
 
Join Date: Aug 2011
Posts: 1,674
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by gaming_mouse View Post
Ok, I read those, and I don't know what to say. I think I don't believe it. Literally. They aren't using a monorepo. Just no.

Clearly I'd need to see the whole thing in action and maybe it would make more sense, but for now I'm going with it's a conspiracy.
It's a pretty big conspiracy:

https://arstechnica.com/information-...it-repository/

Microsoft, Facebook and Google are probably the three most respected software engineeing organizations in the world.

Quote:
Originally Posted by gaming_mouse View Post
Also, there's something wrong about focusing on the "repo" part.
But that was what was being discussed:

Quote:
Originally Posted by candybar View Post
I personally favor mono-repo and having all technical design doc in that repo so that code changes and documentation changes can be reviewed together but what typically happens when you have lots of repos, lots of applications, which also means lots of different teams doing their own thing without anyone else knowing, is that things leak outside of repos as people build and use their own documentation solutions and are no longer aware of how other teams are doing things.
Quote:
Like, no matter what you do, you break things down somehow. You can't get around it. They draw the boundaries somewhere. You don't have a mono anything that big. Not really.
I'm not sure what your point is here - obviously a monorepo doesn't preclude project or component or service-level organization within the repo - but the flipside of this is that no matter how you divide things, you still have to deal with the whole. Having national borders doesn't make the concept of the earth go away and having a bunch of rooms in a house doesn't mean you don't have to maintain the house. I think a huge part of the recent movement towards microservices and microrepos and microapps and what not is due to some developers not understanding this and being driven by this irrational fear of large systems, perhaps due to having been burned by large poorly architected systems in the past. And maybe resume-driven development and a degree of hubris that some companies have regarding their true nature (we are a platform company - no you're not). Yet, somebody still needs to look at the whole thing and decisions have to be made at that level.
candybar is offline   Reply With Quote
Old Yesterday, 10:55 PM   #30238
suzzer99
Carpal \'Tunnel
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 82,645
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Microsoft, Facebook and Google are probably the three most respected software engineeing organizations in the world.
Yeah but what they do with infinite rock star devs, no offshoring, and managers who actually understand and care about things other than "Am I on budget and is my feature working?", isn't always replicable in the other 99.9% of large companies out there.

I even touch on the theme my node talk - "Node for the Rest of Us". I came up with a node framework that offshore devs can use to build features w/o getting themselves into too much trouble. I imagine at Google or FB I'd give feature devs a lot more leash to the point where my framework would be a very light library.

We tried to replicate the Netflix microservice back end. Jury is still out on whether it's going to work. But there have been massive growing pains. One of the biggest is a vacuum of leadership over the entire over-arching application. I'm not really sure how that came about but usually these things are a combination of political inertia and lack of caring. I imagine Netflix doesn't have those problems.

/ramble

Last edited by suzzer99; Yesterday at 11:11 PM.
suzzer99 is offline   Reply With Quote
Old Yesterday, 11:39 PM   #30239
gaming_mouse
Carpal \'Tunnel
 
gaming_mouse's Avatar
 
Join Date: Oct 2004
Location: taking notes on u (see profile)
Posts: 13,726
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by candybar View Post


But that was what was being discussed:
i think i literally don't understand what it means. surely every engineer at google is not cloning a repo of all of google's code to their laptop. so what does it mean?





Quote:
I'm not sure what your point is here - obviously a monorepo doesn't preclude project or component or service-level organization within the repo - but the flipside of this is that no matter how you divide things, you still have to deal with the whole. Having national borders doesn't make the concept of the earth go away and having a bunch of rooms in a house doesn't mean you don't have to maintain the house.
It exactly does those things. The really big stuff, the whole world stuff, isn't managed top down. It's an emergent property from the smaller domains that people actually work in.

By your argument, how does npm work? you don't make npm go away... but that doesn't matter. nobody has to deal with that whole.

Quote:
I think a huge part of the recent movement towards microservices and microrepos and microapps and what not is due to some developers not understanding this and being driven by this irrational fear of large systems, perhaps due to having been burned by large poorly architected systems in the past. And maybe resume-driven development and a degree of hubris that some companies have regarding their true nature (we are a platform company - no you're not). Yet, somebody still needs to look at the whole thing and decisions have to be made at that level.
there is absolutely no way anyone is seeing "all of google's code" and its dependencies and making decisions about it in that way. it's not possible. code that big can't be managed like that. this was my point. ok, it's a monorepo. i still don't know what that means. but i know it doesn't mean that people understand it all. they know generally what services are available, and then how to search down with more granularity. exactly the way you'd find a library on npm or rubygems or wherever.
gaming_mouse is offline   Reply With Quote
Old Today, 12:42 AM   #30240
candybar
old hand
 
Join Date: Aug 2011
Posts: 1,674
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by gaming_mouse View Post
i think i literally don't understand what it means. surely every engineer at google is not cloning a repo of all of google's code to their laptop. so what does it mean?
It's in that article:

Quote:
Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE13 file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository. CitC supports code browsing and normal Unix tools with no need to clone or sync state locally. Developers can browse and edit files anywhere across the Piper repository, and only modified files are stored in their workspace. This structure means CitC workspaces typically consume only a small amount of storage (an average workspace has fewer than 10 files) while presenting a seamless view of the entire Piper codebase to the developer.

All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review.
Quote:
It exactly does those things. The really big stuff, the whole world stuff, isn't managed top down. It's an emergent property from the smaller domains that people actually work in.
The real big stuff is often managed top down - the US, which is much bigger than Google, has a federal government that collects and spends trillions of dollars, manages a large nuclear arsenal, the military, social security, medicare, just to name a few, all in accordance with the laws that are created by a fairly small body of people. Of course there's a lot of autonomy and decentralization inherent in any large system but you don't just say this whole overarching structure is entirely useless because you can't control everything perfectly.

Google is a company with a small number of products and a CEO who is accountable to the board of directors and shareholders. All of the stuff in it has to be absolutely manageable top down, even if that capability isn't utilized all the time. If you're in charge of Google Search or GMail or some other humongous project, you can't tell your boss, you know what, I have no idea what's going on, the product is just an emergent property of all these devs doing their own thing. Obviously the centralized planning is informed and influenced by what happens in the trenches but that doesn't mean you don't want to have that capacity.

Quote:
By your argument, how does npm work? you don't make npm go away... but that doesn't matter. nobody has to deal with that whole.
This is because npm doesn't own the contents and each of the repos is more or less its own user-facing product with a specific owner and no one needs to be able to make changes to something they don't own. There's no overarching architecture that ties these repos togeher. Google owns all of that source code, they are not letting things randomly evolve. All of these (maybe not all, but large overlapping portions of it) work together to produce more or less a single product.

Quote:
there is absolutely no way anyone is seeing "all of google's code" and its dependencies and making decisions about it in that way.
It's like saying, you know what, we can't be expected to follow the laws because we're too big and can't watch everyone. Or there are too many cells in our body so they must all be working independently and there can't be a centralized mechanism for controlling our behavior. Or a million-strong army cannot possibly have a central chain of command. None of this is easy or works perfectly but it's obviously possible at some level. You can't just throw your hands in the air, I can't micromanage everything so manage nothing and let things be.

Quote:
they know generally what services are available, and then how to search down with more granularity. exactly the way you'd find a library on npm or rubygems or wherever.
No it's more like, you know what I need to change 5000 places where my library is used in a way that I don't want to support in the future, let's change all of them programmatically and see how many tests I break. Or, welp, there's this security vulnerability found in a commonly used library - let's see if we can fix this across the entire codebase. A well-managed multi-repo system and a monorepo are fairly similar when it comes to reading information, though I've never seen a well-managed multi-repo system at scale that functions well enough to approximate a monorepo in this regard. But at least it's theoretically possible. Where they completely diverge is when you need to make changes - you can't have an atomic commit across multiple repos, that is logically impossible.
candybar is offline   Reply With Quote

Reply
      

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Forum Jump


All times are GMT -4. The time now is 05:20 AM.


Powered by vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © 2008-2010, Two Plus Two Interactive
 
 
Poker Players - Streaming Live Online