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.
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.
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.
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'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.
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.