|
Ephphatha posted:Guess this is the most appropriate place to ask, there was some talk in one of the other threads about some articles detailing why over-using globals in code is an anti-pattern but I've never managed to find anything more comprehensive than a vague blog post. Anyone have any material they'd recommend? I don't expect anything to change at my workplace but it might make me feel better to know I'm not the only person who wants to actually use appropriate scoping to the extent the lovely languages I have to code in support it. Ultimately, you want to be able to reason about code. Code that is easy to reason about is easier and faster to find bugs in, and makes future maintenance work go a lot smoother. The easiest pieces of code to reason about are idempotent functions. That is, functions that take a set of input and return a set of output, and every time you send the same input in, you get the same output out, without relying on anything except what's in the input set, and without modifying anything outside of its scope. (Side note: these functions are also the easiest to unit test, because each test is given-input-return-output?) Global variables make this reasoning harder. If a piece of code refers to a global variable, then in order to reason about the code, you need to know everything about where that variable is modified. And if that variable is set in a dozen places that themselves rely on other global variables, you start building an awfully complicated dependency graph in your head just to understand a single function. The more stuff you as a developer have to keep in your head to reason about code, the more likely you're going to get something wrong and accidentally cause a bug. Never mind what happens when you have a team of people modifying this sort of code, and you're not even aware that one of your colleagues added a new way for that variable to be modified, and in such a way that it breaks the function you're looking at. Programming is about managing complexity, and global variables add unneeded complexity. I'm a fan of Rich Hickey's Simple Made Easy, which kind of touches on this sort of thing. Sadly, I can't think of any good resources out there to make the argument that globals are bad, because doesn't everyone already know that? (Obviously not, sadly)
|
#
¿
Nov 27, 2015 05:34
|
|
|
|
| # ¿ Apr 28, 2024 10:08 |
|
|
Actually, misunderstanding on my part. I was under the impression that 'idempotent' and 'pure function' were essentially synonymous. If idempotent functions can have side effects, then it was the wrong word to use; I meant pure functions. My bad, but now I know!
|
|
#
¿
Nov 27, 2015 19:15
|
|
|
Che Delilas posted:The management would rather we just keep making GBS threads out inadequately-tested, buggy garbage because it looks like we're doing more that way. Classic American short-term business strategy: present our customers with an ever-increasing pile of annoyances and almost-adequate features until they get fed up and fire our asses. Fortunately despite their complaining they seem to be willing to let us run with this a while and try to smooth out the process and address the problems. One of the things that I really like about where I work is that management is completely on-board with taking the time we need to make things right. As an agile shop, we try to work closely with our client and if new priorities come up, they jump to the top of our kanban, and we still try to provide some value with each story. But once we start a feature, we want to finish it and finish it right, and our management will fight for that as much as they can. That doesn't stop the client from still asking for stupid and impossible timelines, but...y'know...clients.
|
|
#
¿
Dec 18, 2015 05:46
|
|
|
As my last PM was fond of saying, you can either pick the features you want released, or the release date. Not both. Frankly, I think a Kanban approach is the best way I've seen of managing work. It clearly communicates the order things will be worked, and also pretty much enforces some prioritization. When talking with the client, any time they want some new feature, you can say "okay, where do we put it on the board?" and it shows an obvious deprioritization of the other work. You can also go to them and say either "tell us where the line is by cards, or give us a date and we'll work things in this order".
|
|
#
¿
Dec 23, 2015 04:59
|
|
|
Volguus posted:At the end of the day, that's the entire point of agile: "Don't loving bother me with your poo poo today. Wait until planning meeting". Isn't it? Err, no? Agile doesn't proscribe a planning meeting at all, and "responding to change over following a plan" seems to contradict that mentality. Agile is "hey, we just realized that we have this other thing that's really important to us" and there's a discussion, priorities get reorganized if it makes sense, and you keep going with the new priority list (kanban really helps with this, in my observation). Maybe that means you get the thing when you want, maybe it needs that you have to compete with other people who need things also. That's why you have a face-to-face conversation with the people involved and talk it through.
|
|
#
¿
Jan 16, 2016 01:14
|
|
|
Cuntpunch posted:I haven't yet seen anyone really read that as anything other than "a million meetings, both scheduled and ad hoc, are great because INTERACTING!" In the groups I've been in, we've always read that as "given an option between just turning around and talking to each other vs. establishing a formal process for something, pick just talking to each other". For example, if someone needed to do something that meant no one else should push for thirty minutes, instead of building up some process of notifying people through a tool and things like that, just loving turn around and say "Hey, no one push for thirty minutes, okay?" and everyone says "Cool" and turns back around and gets back to work. If you read that as "more meetings" or "more tools", then you're doing agile wrong.
|
|
#
¿
Jan 25, 2016 18:05
|
|
|
Click Beelay posted:Now the hosed up part, I never used any of those technologies throughout my degree. The last three I'd never even heard of until I started researching after the interview. I was very up-front about my experience and was assured it wasn't an issue, though I was made aware that I "will be learning a gently caress load". When I graduated college, Ruby on Rails was still in version 1, and among my fellow students, I'd only heard it once or twice, as a "hey, I heard about this thing, and it's interesting, but not worth using yet" sort of thing. Also, the iPhone wasn't out yet, and mobile was definitely not a thing. Hadoop was not a thing, and I don't remember ever hearing about "big data" in school. We did all of our AJAX calls by hand in my Internet Programming course; at that time, jQuery didn't even exist yet. Neither did node.js. Or Angular. Or whatever the new hotness is. Stack Overflow did not exist. There was no Github (git wasn't even particularly well-known; we used SVN in my one class that mentioned version control). My Software Engineering class focused primarily on waterfall, because agile was "just a fad". We never talked about writing unit tests or anything like that. Some of that might have been the failure of my professors, but some of it was simply that some things were just not as widely known about in the software engineering world. That's just the nature of the industry: things change quickly, and new technologies arrive on the scene. It's much less (in my opinion) about whether or not you've used each technology; it's much more about being able to pick up new stuff and keep building. Learn how to keep getting better.
|
|
#
¿
Jan 31, 2016 05:58
|
|
|
Vulture Culture posted:Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement? On my previous team, we had a weekly estimating meeting on new stories in our pipeline. To do the actual estimating, we'd all read the card, then raise our hand (or otherwise indicate) when we'd made an internal estimate. We'd then go around in a circle and say our own estimates. I think the highest ended up being what we put on the card, but that never really mattered to us. It was more about seeing "are we all on the same page regarding the scope of this story?" If one person said 8 hours and another said 40, we'd go "whoa, why so high/low?" It often led to good conversations about what actually needed to get done with a little bit of how, and meant everyone knew something about each story, so they wouldn't go too far off the beaten path if they ended up pulling it. I liked it well enough, though I thought it was stupid to use hours and we should have done a sizing system (< day, 1-3 days, 1 week, longer, or something like that). In terms of actually using estimates for planning or communicating with management, I thought they were worthless, and I don't think we should have been sharing those estimates outside of that room, because they just lead to unrealistic expectations.
|
|
#
¿
Mar 12, 2016 05:58
|
|
|
smackfu posted:For our in office setups, the pairing setup is one computer with two displays hooked up in mirroring mode, and two keyboards and two mice. So you don't have another machine to check your email or anything. Some of our stations are set up like that, others are just one big screen hooked up to two keyboards and two mice/trackpads. But a lot of people also bring in personal laptops or have work-provided ones that they use for e-mail/slack on the side.
|
|
#
¿
Apr 16, 2016 23:47
|
|
|
It's also really great for learning about things from the other person. I feel like I learn a lot more sitting there being able to ask "why do you want to do it that way?" as we're writing it than tracking someone down to ask questions when they're no longer thinking about it.
|
|
#
¿
Apr 17, 2016 16:40
|
|
|
Steve French posted:For me, that happens in code review Yes, but there's nothing quite like "Hey, can I try writing this [thing to interface with framework they're familiar with and you're not]?" when it comes to getting some hands-on experience and learning a framework. Though also at my last job, the code reviews were a joke. At my current job, we generally treat pairing as its own code review, so YMMV. Pairing is incredibly socially draining, though, especially for introverts like me. While there are things I like about it in terms of learning, and the rhythm you can get into with people you're at similar skill levels with, I could in the end take it or leave it. But I'll never do remote pairing. That just sounds like pulling teeth.
|
|
#
¿
Apr 17, 2016 16:51
|
|
|
B-Nasty posted:Is there any place to find semi-regional chats/forums for development? I'm thinking like a Glassdoor forums broken out by metro area. I feel like having the anonymity behind a computer might be really valuable to hear people bitching about lovely workplaces or bosses. St. Louis has a "tech industry" Slack, though it's not really anonymous.
|
|
#
¿
Apr 22, 2016 04:37
|
|
|
My work has Slack, but we haven't pushed the button for making it "official" or paying for it, because we 1) want its login to use our Exchange LDAP, and 2) more importantly, we want to self-host it, because something something client information something something. Some people in the company are wanting to move us to Cisco Spark because we have such a great relationship with Cisco according to them, though given how little I've heard about the product, I'm immensely skeptical that it's any good.
|
|
#
¿
May 15, 2016 03:30
|
|
|
Portland Sucks posted:Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I have heard good things about Working Effectively with Legacy Code.
|
|
#
¿
Jul 27, 2016 19:57
|
|
|
Iverron posted:So we're apparently doing a "DiSC Assessment" course as an office next week (devs, designers, social media, etc). After some preliminary googling this appears to be the same Myers Briggs psuedoscience bullshit I've dealt with in far more corporate-y environments. My experience with all of the pseudo-science personality tests is that they can sometimes be good for self-reflection and realization that you do, in fact, do things you didn't realize you did. They can also be useful for starting a conversation about how no, really, people really do think very differently about problems. But if you try to put any more stock in it, like using it to determine what jobs people would be "good" at, then it's going to blow up in your face.
|
|
#
¿
Jul 30, 2016 05:41
|
|
|
Pollyanna posted:Related to testing: if your app depends on a connection to an API to work properly, is it better to bypass it/stub it out, or should the test environment enforce a live connection to the API while running tests? Personally, in an ideal world, some of both. I want to test various normal scenarios and common error conditions against the actual server, because it does catch when APIs suddenly change without documentation, or when the server provides malformed JSON or something. To an extent, it'a a test that covers both the client and the server, to make sure they're talking together correctly. But I also want to stub out a lot more scenarios that build on what I test against a real server (e.g. the real server is "order an ice cream cone with vanilla", and the fake server gets "order an ice cream cone with chocolate" or something like that), and more importantly, to stub out the scenarios that are difficult or impossible to orchestrate on the server. What happens when the server returns 500? What happens when we hit the server right in-between those two cron jobs that both need to run to get real data (yes, this is a scenario I've had to test)? Things like that. I'd say it's my ideal; living up to it is a far more difficult thing, because of practical concerns and time pressures.
|
|
#
¿
Sep 29, 2016 04:08
|
|
|
revmoo posted:put my entire CI process into shell scripts, depending on Jenkins for just Git, credentials, and artifact generation, and nothing else. A nice bonus is that you can switch CI platforms in an afternoon since all of the build logic lives outside of it. This is the correct solution, as much as possible. Let CI tools do what CI tools are good at: scheduling builds. Another bonus is that it's easier to debug builds locally. revmoo posted:Also, protip; generate a 1mb file, commit it to Git, and then put the md5 of it in your deploy script as a canary. Abort deploys if the hash ever fails to match. I'm trying to figure out what the point of this would be.
|
|
#
¿
Apr 19, 2017 20:49
|
|
|
My problem with a Jenkinsfile is you can't run it locally. So, if you want to modify it, you have to commit and push every little modification of trying something.
|
|
#
¿
Apr 19, 2017 21:15
|
|
|
Hughlander posted:We use docker for that Just feels like overkill to me, though I can see the value depending on context. I just like sticking with my Makefiles and bash scripts.
|
|
#
¿
Apr 20, 2017 02:27
|
|
|
|
| # ¿ Apr 28, 2024 10:08 |
|
|
Hughlander posted:Problem there is if QA needs to make a build that by default has debug off but profiling on and targets qa4 for connections but staging for events. We end up having a separate app we've developed internally to handle general configuration like "what servers are you pointing at". And debug/profiling are done based on which build you want (dev vs. prod, basically). At your level of complexity, I can see why you'd go the route you do, and can't fault you for it (though I'd still recommend that all Jenkins does is make it easy to specify the config values passed into the script). At smaller levels of projects, that sort of thing can be overkill. I still stand by "put all the build logic/commands in scripts/Makefiles called by your CI system" 
|
|
#
¿
Apr 20, 2017 04:35
|
|