ThorinJacobs's comments

I've run into this when working with lambdas in particular. Say for instance I want to track the performance of a particular bit of code in a standardized way. I can write a method that takes a supplier and handles the performance tracking while calling the supplier and returning the result. This way tracked functions don't have a load of eg. timer initialization etc. If the supplier throws a checked exception, it should be caught and handled by the code that actually cares about the call, not the performance wrapper.

Unfortunately, because of the way Java handles checked exceptions, I can't feed the supplier with a lambda or any other method reference that I'm aware of that throws a checked exception and let it be passed up to the original caller directly. So I need to catch my checked exceptions and wrap them in an unchecked exception to catch. Not pretty.

There's probably something I'm missing but the language certainly doesn't go out of its way to help with this sort of thing.

Sure, but the migratory patterns of Canada geese are just a little off-topic, don't you think?

Have you considered Crapcha? https://crapcha.com/

If my experience in retail is any indicator you're lucky if that request gets approved....and even luckier if your manager remembers that they approved your request!

I agree with this sentiment and would like to see more this sort of this not just for moderators but for every "low skill" job. Especially the C-level employees and shareholders - no one should be asking anyone to do something without either A) doing it themselves so they know what they're asking or B) treating the workers as experts whose opinions and requests should be taken seriously.

I answered "both" because I'm not running all of the projects I'm working on and some of them prefer tabs and others spaces - so I just go with the convention that that particular project uses.

+1 - Another great example of difficult games as parody is I Wanna Be The Guy (https://en.wikipedia.org/wiki/I_Wanna_Be_the_Guy). Take all the existing conventions and stereotypes of difficult platform games and exaggerate them to the extreme.

This was deliberate on Douglas Adams' part [0]. It's all part of the joke. Other notable sections are where the game actively lies to you about being able to access a particular room (you need to try to enter several times in a row), and then sulks when you call it out and lies about the contents of the room.

[0] https://en.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_th...

The notation for player death appears to be "JIGS-UP". Glad to see the classic Infocom sense of humor is present in the codebase too.

To add onto your comment - I'd also consider a work environment that automatically assigns the documentation, test-writing, etc. to a gender minority (or other minority) to be toxic.

This looks really cool and definitely fills a need I've had when doing web front-end.

Does the UI viewer work with dynamic content such as that loaded from a back-end (or say, from a sample .json file in the event that we want to skip the API call)? I've done a lot of work in WPF/MVVM applications where everything ends up becoming a ResourceDictionary and breaks the Visual Studio UI viewer, so I'm curious how you handle it.

Also, do you have any plans to incorporate a compatibility view? It would be really cool if I could select an item from a combo box and see what my UI would look like in (say) IE or Opera

Hi, clinically diagnosed here and while I can only speak for myself, the only time I've had an issue with someone who self-diagnosed was when they consistently brought up Problematic topics and played the "autistic, can't be offended" card.

My response to a self-diagnosed or clinically diagnosed person that was having a behavior problem would be the same, so why question? Why not just be kind and understanding?

One reason to suggest a smaller max character count is to assist those with impaired vision. I'm highly myopic and, while my lenses correct for it, I still seem to get eyestrain when using the default font/sizes in most IDEs. Bigger-screen monitors counterintuitively seem to make this worse, not better.

I can only imagine that this would be even more important for individuals with more severe vision impairments.

The main benefit for me is the ability to quickly and conveniently see the commit history and diff as well as branches' current position. If you're already comfortable with doing the same in CLI, then you're probably not going to gain a ton.

I like Sourcetree for this particularly because its buttons map fairly well to the actual CLI commands that it will be executing, and makes it painless to open a CLI terminal for instances where I want more fine-tuned control.

These are totally based on my own experience and may not make sense for everyone but:

- In the main projects I'd be working on, how many new files are necessary to consume data from an outside source (say JMS) and log the result.

- What is the frequency of your releases

- How long does it take for a minor feature request to make it from initial conception to delivery to the user

These aren't actually specific to a startup largely because I haven't been burnt by a failed startup. YMMV

I've had both good and bad experiences with checked exceptions - it can really depend on the team!

One of the parts of Lombok that really works well for me is that its notations are completely optional and fit many different levels of granularity as you see fit. Don't want sneaky exceptions? Don't use them!

I mostly end up using it to make my Java code feel like C# though...

I enjoyed the list and examples but I feel the hypothesis in the introduction is flawed.

All anecdata, but I expect those of us who read these sorts of lists will likely understand them quickly without needing examples. There's a large number of developers that are not reading software blogs and lists and are not applying much thought to their programs beyond "how do I meet the minimum requirements put forth in this user story". As long as those sorts of developer continue to be prevalent it's partly on the business to specify these requirements explicitly.

Tragically I don't see this changing any time soon.

I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here

I'm really excited for this year's AoC, and trying to get other devs at my work involved too!

Last year I tried to solve at least the first few days in a bunch of different languages, doing Red/Green TDD so I could learn how to set up a basic project and do tests in languages I was less familiar with. Still trying to decide if I should take that approach again this year or focus on getting every day done in a single new language.

How is complying to another's pronouns harming you in any way whatsoever? Meanwhile, you're harming them greatly by misgendering.