They should be related to a #language#technology task, able to be automatically evaluated, with training and test #data able to be distributed to participants at low- or no-cost, and should be fun!
I'm doing some monitor shopping and am looking for recs. I do #programming, so I look at code and browsers all day. Priority is for screen real estate and text sharpness. There's a budget, but it's sizeable enough to not be a (big) factor here.
@xavdid I have the LG version of that 40” Dell ultrawide. I like it pretty well, though the pixel density is still not ideal for use with Apple. I find myself wishing I had the 5k2k resolution in a 34” or 38” ultrawide instead. It’s also silly expensive. Text is good on it, but still not “Apple good”. It rules for doing video and audio editing though (anything with a horizontal timeline). Also I’ve liked running D&D from it.
@xavdid That 27” Apple display is gorgeous, but a single 27” screen may feel too limiting. I also hate the stupid non-removable cord situation and that you have to pick a stand type at purchase time and can’t self-serve a change to a vesa mount.
What I really want Apple to make is a Retina ultrawide, probably in the 34-38” range.
@virtulis I’ve never really understood what node-gyp actually is or why I need to care about it, just that it occasionally pops up in build error messages and when I see it I get irrationally angry.
@davidbisset one thing i found that can convince a lot of developers to stop doing those one liners "because its fewer vars and faster" is if the language can stop being compiled at an assembly stage.
the compilers of most languages will end up making ::temp# variables to assign the results of each call to, ergo being the same as if you had declared them yourself.
scratch, the 'language' for teachings kids the basics of #programming, has better first class support for async work than a bunch actual programming languages
@luis_in_brief@sirlan well, it is easier to do async when there aren't any actual hardware threads to worry about, and it is all happening in a virtual machine.
I prefer Snap because you can do first-class functions, plus they have some pretty incredible lanugage additions like "SciSnap!" which give you access to SQL databases and linear algebra primitives, and they even have an APL implementation. Anyway, Async works the same as in Scratch.
But it does get a little tedius if you need to create more complex chains of async actions, like for doing animation. Then I start to wish it had a good built-in nonlinear editor.
@ramin_hal9001@sirlan sure, lots of hard problems when you want to use that sort of model for more complex applications. Still, I wonder how different CS would be (will be?) when the assumption is that those are compromises rather than defaults.
One job interview question I try to ask that I strongly recommend people copy is “can I see your list of pages?” Ideally the full list from PagerDuty but whatever you can get is good.
This tells you everything you need to know about the team you are joining. See a lot of pages that repeat and are snoozed forever? If a team isn’t empowered to fix alerts that wake them up, that means they’re not empowered to do much of anything.
What’s funny is people who try to track and account for pages instantly know why I’m asking, but if you don’t care often they’ll let me see the whole list which is amazingly informative. #programming#interview
@hungryjoe I think you need to be careful with that because of the LACK of semantic distance. Ideally, there would never be any diagnostic emitted by the local format check that wasn't emitted by the CI format check and vice-versa. Using the unit test framework for one and not for the other just makes it more likely that the processes diverge.
They should be related to a #language#technology task, able to be automatically evaluated, with training and test #data able to be distributed to participants at low- or no-cost, and should be fun!