A: Profanity.

[end of line]

I know it's pedantic to have this discussion outside of a classroom environment, but Kilogram is a unit of mass and not a unit of weight. I suppose it was the electroshock therapy administered in science courses that makes it sound like fingernails on chalkboard to me when someone gets it incorrect in a publication.

Try the Wayback machine. I found it pretty easily. Really interesting trick. He made a simple HTML file with a link in it, and the HREF of that link has all kinds of crazy garbage in it (unicode characters) which cause the webkit engine to spaz out. Even copying the source out of chrome and pasting into Notepad++ made the text editor freak out a little bit.

I applaud your efforts, and I think that you're making valid decisions and are doing very good things to salvage the brand. Redesigning the site is a good step in rebuilding the brand. You might want to make it more apparent that the site is under new management with the new manifesto very clearly spelled out from page 1. Sorry if I came off really harshly, I actually didn't know the site changed ownership and I've had projects hosted there (now defunct) for well over a decade. I really hope you are successful in your efforts, but the brand took massive damage so I'm still skeptical at your odds to be frank. But don't let that deter you -- ultimately I'm still just another jerk on the internet with his own opinion. ;)

There's literally nothing they can do to rebuild the confidence that was lost, short of just rebranding and building a new community. I don't know of anyone who has still forgiven them for injecting adware into downloads. I agree with them that developers are best served with as many options as possible, and that's why so many people have ditched them years ago. I appreciate the challenge of providing a community free service and having to find affordable ways to keep the lights on. But they botched it. Game over, man. Put a fork in it because it's done.

This episode of The Orville reminds me of this -- it seems that people just make split decisions because they can't be bothered with hearing and weighing the evidence presented to them. Probably because people aren't being asked to think into the areas of possible ambiguity, we just raise them to pick from a selection of choices. The millennial generation might as well be called the multiple choice generation. So glad I'm from the "Choose your own adventure" generation. ;)

IANAL, but almost none of the original series or movies used "officially licensed" uniforms or props. They just used whatever the costume department or prop department came up with for an episode. From movie to movie the outfits were always different. Even from season to season, in many cases. What then, do any of the genuine-looking costumes or props have anything in common with the licensed ones which are generally plastic toys, or are made of cheap fabrics that are poorly stitched or just outright glued together? I'm sorry, if Paramount is going to put this bird-cage fodder in their requirements then they, too, need to seriously commit to improving the quality of the products they're trying to force on the fans. The only other logical option is revise the requirement so that people trying to make a believable fan fiction are allowed to use self-made articles of, unquestionably, higher quality than the mass produced garbage and NOT SELL THEM. Because that's how you respect the trademarks and copyrights, to not sell knock-offs to undercut their bottom line. Maybe something for the CBS folks to consider is that THE STAR WARS FRANCHISE DOESN'T DO THIS CRAP TO THEIR FANS. (They do other crap, but not this. ;) )

[Caveat: I've worked for large companies in this space since 2000 and do this for a living. I also am a avid supporter of open-source software and an active contributor to GPL and Apache-licensed software projects.] In order to try to sidestep some of my personal bias, I'm not going to recommend a solution, but I will let you know what the drawback is to using an open-source solution for this kind of thing and where the line in the sand is for what a large implementation would want, say a Fortune 500 company, vs. a small brick-and-mortar company or medium size business. For a small company who runs their own hardware, and has a few IT guys selecting the stack and has little or no budget; then the most likely solution that will work is one of the popular open source frameworks. Even more so for a medium-sized company because if IT is running the show then there is enough hands-on-keys to work around all the obstacles and find solutions to common problems, growing pains, customizations, etc. There comes a point, though, where the inflexibility of these systems shows through and the design of these have you painted in a corner so much so that you're virtually rewriting half the stack to do things they way you wanted it. On the other hand, if you wanted a simple solution and the design fits your needs then that's fantastic. You don't get security as a guarantee so unless you have a network admin with a brain, you're going to have some serious problems one day. Once you get out of that space, though, in larger companies the first thing that you don't have is an IT-run solution. Sure, you get a server maintained by a more general IT group of admins who really don't want to look at someone's code to figure out why the server is performing or not performing. It's not a question of ability or talent, it's because they're much more worried about keeping the exchange server running, keeping sharepoint up, and possibly 25 other production systems. So troubleshooting a server used by the marketing department is not something they would want to sign up for willingly. This is generally the point at which all open-source solutions fall flat; because once you want to customize them, apply regular updates, etc then it requires some level of support. The open-source products generally require so much customization that the supportability and upgradeability is questionable at best. So either you use a commercial product designed to be upgraded, or you use an open-source product and put more sweat equity to keep it patched over time. More importantly, many of these solutions do not scale terribly well in some areas compared to the larger enterprise systems. If you're trying to serve 50+ internal users and publish content to be viewed by folks in the millions, chances are you're also willing to actually pay money for a system that was designed for that kind of thing. As scary as they look, this is where the scale of things like J2EE start to make a lot more sense. It's no good to try to have a single point of failure (aka one single Authoring content server) when the daily operation of your website can be monetized in the hundreds of thousands. Putting J2EE aside (as I have for the last five years), unless you're using platform built for horizontal scale then things like failover or on-demand scaling will really bite you hard the moment the server goes down during that critical close of the quarter -- when everyone and their cousin is trying to meet their deadline. So back to the recommendation: Use an open-source solution but only after you've assured yourself that you have the resources on-hand to keep it running, and it will absolutely meet your demands of scale now and in the future. Otherwise whatever you put together today will just get chucked in the bitbucket within 2-3 years. Same goes for commercial products too, but generally speaking if you're in a position to pay for one of those then you're also likely to invest in your people to support them as well. Either way, you get what you pay for whether it's the license/training cost of commercial vs. customization and salary time for someone to maintain something that was "free." Free software means freedom, it's not always free from an operational perspective at the end of the day.

Install the open jdk if you want to avoid the nag of bundled software. It's curious to see how easily people complain about freely provided software when the advertising partnerships are part of how some people keep the lights on. You may not like the ask toolbar, nobody does, but would you rather pay for a license to use the JVM?

As someone that maintains a java-based emulator for several years I couldn't disagree more with that.

Then you are doing it wrong, dude. You should make sure to check "Generate debugging info" under the compile settings for the project, which eliminates the need for the IDE to do it on-demand later. You can connect the debugger to a running instance by clicking "Attach debugger" as long as the process has JPDA enabled already. I do it all the time when I do J2EE or Sling-based dev work since the app servers I run locally have JDPA enabled for that purpose. If you're debugging a desktop app then, yes, you must tweak the parameters ahead of time, or just remember to run with debug instead of clicking "run", but that's minutiae and can be easily resolved by a little self-organization (e.g. decide if you are debugging or not before you launch the app) As for the flaky dependencies, were you using a Netbeans-defined project or a Maven one? If you define your project as a maven project then not only do you get simplified dependency management (which I use without any issue with both large reactor project structures as well as sibling-level dependent ones) but you also get CI support for Hudson/Jenkins. Incidentally, Netbeans can talk to Jenkins directly if you configure it to do so. If you were using a maven project structure and you still couldn't get it to work then you might have been doing something wrong (or just violated the KISS principle somehow.)

I've been using Netbeans since version 3.6 and am quite pleased with how it works, even in the recently released 8.1 beta. I've tried JetBrains and it seems fine enough for what you pay for (except the maven support feels very clunky and not very seamless, IMHO.) But feature comparison vs. price paid? Netbeans wins, hands down. I've tried Eclipse many times over the years also, but come to the same conclusion: I still don't personally like using Eclipse. Therefore I keep going back to Netbeans because it has 90% of what I need and there's plugins for the other missing 5%. The rest? I have a command line and I'm not afraid to use it. You can use whatever tool(s) you like, but I've been coding in Java professionally since 2000 and you can uninstall my copy of Netbeans when you pry my harddrive from my cold, dead hands.

There are a number of titles on NES that I can think of such as Empire Strikes Back which only look correct on CRT or anything that does proper NTSC color artifact emulation. (and actually sonic games on genesis too!) I've written a game editor for Apple // graphics which uses NTSC artifacts as part of the editing experience -- and also part of the image dithering/conversion algorithms -- and believe me: It makes a huge difference when you are designing graphics with a 6-color palette where you actually get an extra handful of extra "fringe" colors when using some combinations. If you are still unsure, use an emulator with NTSC emulation (Blargg's is great) and then switch over to plain RGB. There is a huge difference. Also, a final note on this (Caveat: I am an emulation author and this information is in a very well written wikipedia article on Y'UV if you want to fact check me...) You will NOT EVER get the same colors from RGB than you get from a CRT. The color spaces are different. Emulators can simulate (and in some cases very well) what an analog display does, but it only goes so far. In the NTSC-to-RGB conversion process you wind up having to transform from one color system (Y'UV) to another (RGB) using some rather simple math but then you also have to alias the results to fit the values (which are often outside the 0-255 range). There are colors in the Y'UV spectrum (I'm talking about the Apple colors but there are some on Atari and NES too) that are so saturated that they look completely neon, and those colors actually don't exist in the RGB spectrum at all so you wind up with a rather muted look compared to the real thing. A scan doubler is okay I suppose for this, but really if you want it to look old school nothing beats the real warm glow of a CRT. If you want to play retro games on an RGB screen, just use an emulator. They're cheaper, and if done correctly you're lucky to ever really notice a difference. :-) I think that you can take a Raspberry Pi and make a dedicated emulator solution for 20% the cost of this scan doubler solution and be just as happy if not happier.

Linux users could use the Gnome-shell-timer extension, which is perfect for Pomodoro. Of course cell phone timers work well. My most productive weeks look like this: 1) Spend the first hour of the day going through the list of to-dos. If anything is too vague or undefined, I either need to set aside time to research it, or if I break it up into small measurable pieces. These are key because crossing them off later lets me know I'm not a total f**k-up. 2) I keep this to-do list in a very simple editor called "Focus Writer" which occupies the full screen when it is active. This prevents me from getting immediately distracted. 3) Once I get the tasks listed, I prioritize them. Usually the ones that are absolutely important go to the top (criteria: If I skip this will the customer or my boss yell at me?) 4) I stick to the list. I really should try pomodoro because I too get way overly distracted. You're not alone. Damn internet. My core non-web programming tasks get done faster. Why? Because when I'm testing non-web apps, I don't have a browser open. I don't have to google how to solve basic javascript problems. I just get stuff done. But when I'm dealing with a quirky browser behavior with extJS or jQuery.... yeah, where did the time go? And why am I reading TheOatmeal again???