windust

sure. It used to be that major releases were tied with major features. InvokeDynamic on 7, Lambdas on 8, Jigsaw on 9. So since these were the features that were expected, the release only shipped when they were fully baked. Now is on a train-release model. You get whatever is ready to ship (big features can't delay a release anymore).

Installing the JDK has no ask toolbar (vs the JRE which is just the client libs)

not quite patterns, but preferences :)

https://blog.xkcd.com/2010/05/03/color-survey-results/

http://cdn.slowrobot.com/524201613515576555.gif :)

Can't stress this enough. If you have Employee Incentive Options is way better to exercise them as soon as they are vested than to wait (if thinking of exercising at all). When you exercise them you pay AMT on what they are worth when exercised (of course the "fair price" is a hidden secret left for the CFO). As time passes, the "fair price" is probably going to keep increasing, but with no liquidity and inability to sell your options you are stuck with the AMT with the fair price at the moment of exercise

or we can skip a generation and go to JRuby ;)

Can you attach the JDK sources and put a breakpoint in the HttpRequest constructor? Then you should be able to find the culprit right?

Mandatory xkcd comic https://xkcd.com/1497/

I disagree, I think the hard skills for being a successful software developer are picked up by honing your craft daily working on the same project. Hackathons are too contrived since the goal is to have a finished product in 24 ~ 48 hours. Every time I have done one I throw away all the "Danger, Bad practice" signals from my sub conscience and work towards finishing the product/idea. Things that are important like maintainability (even if your hack is successful, and get investor funding you want to re-write it properly), coupling, testing, documentation, API, Memory profiling, Logging, performance optimizations, design patterns are thrown out the window to get that idyllic prototype out. Even working as a team, there is very little you gain from spending 48 hours with (mostly unknown) individuals than it is for your peers in a job where you actually have a favor economy.

And I don't mean that there isn't any value on hack-a-thons. I think you're right on dealing with deadline pressures and the ability of working yourself out of a problem in a pinch are valuable skills. I just don't think that's where the "hard" skills needed to become a successful software developer are learned.

I would biased-ly recommend javapubhouse.com (I host it). Is a tech dive on a Java topic that you can listen while on the radio/threadmill (you can close your eyes and follow the code) :)

Neat, will check it out. Yeah, Kanji might be a tall order right now (still working with Hiragana/Katakana first), but found the forums. Kinda nice to find a community of Japanese learners

Spanish native speaker here. I'm still waiting for my ah-ha moment (I'm learning Japanese for the past 4 months at a rate of 4 hours per week), I do hope it arrives. It took me probably 5 years to be fluent in English, and probably 4 more to actually be good enough as to read/write government proposals, abstracts/CFP, and finally co-authoring a published book "Java 7 Recipes"; my accent still lingers (javapubhouse.com if you want to hear it), the Ys, Js all come out with the same sound for me. I did learn French for 5 years, but lost most of it due to not practicing it. Learning French coming from Spanish felt a little weird because there are gender swaps (for the inanimate objects) that do trip you up. Did try to learn German for 5 months just after finishing French, so I ended up sounding like a French speaking German, which my teacher hated (and whom scared me away from the language!)

I noticed that I'm not really going anywhere fast with my Japanese and I think I might be doing it wrong (listen to one hour podcast while running / biking). Some stuff sticks but in general it does seem that my progress is nowhere near what I had when learning the other languages in a more structured format.

Mandatory XKCD Time travel Comic http://xkcd.com/716/

// and Wing Commander including Armada, Descent, and Freespace (even Star Wars Tie Fighter). The last Space Sim that I found was Strike Suit Zero (http://store.steampowered.com/app/209540/) which is nice, but not as epic as the WC series.

Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.

drooling for crunchyroll support

In our company we understand that testing up-front can be off-putting, but we rather pass up a great candidate than hiring a poor one (we do subscribe to Polsky view on candidates http://www.joelonsoftware.com/articles/GuerrillaInterviewing...). We allow them to test at their pace (codility.com) from home first, then we re-test them on-site (to avoid the 'someone doing my homework' effect). After that the next interview is pretty much talking on the code written code and approaches or decisions that the candidate took. So in that sense is a great piece to further discussion.

The issue is that where I work we can't subcontract as a way to 'test' for candidates. The code is so proprietary, and have so much red tape (Options Trading platform) that we don't trust anyone unless you are full-time. Also, the code is fairly complex and embedded in it's industry-speak that unless you come from the same industry subset, you will not be productive (like knowing what Black-scholes, instrument, or delta means). So the investment to getting any good developer to be able to produce is immense. We considered subcontracting for assessing a candidate, but it is fairly hard.

Also we have seen people that do extremely well on every other aspect of the interview but can't deliver when asked to write a piece of code. Good or bad it does show your ability to work under pressure (I am not sure if it's extreme in the financial industry, but stress levels here run fairly high... for a fun read http://codesnipers.com/?q=interview-the-wall-street-programm...). So when you're getting your coffee, someone comes and says 'we need to fix this' it will probably be as intimidating (or more) as having a code interview.

Lastly, maybe because we've seen it often enough, there are a ton of programmers that can't write code (yes, the fizzbuzz crew). Having the codility test filter in front of all eliminates a lot of that chaff we see, so we don't even bother with the candidates unless they get a good-enough result in codility (we do look at the code, not just if it passes/fails the unit tests, but we don't bring the candidate for an actual interview until we have a reasonable expectation that they can program). We understand we will miss Ike Ellis, and we accept that as part of the tradeoffs between time and opportunities.

You're assuming that the code is executing in the way you read it, which is false. With the advent of branch prediction and Instruction reordering in CPUS (to gain performance), a CPU have the liberty of reordering operations for efficiency (http://en.wikipedia.org/wiki/Out-of-order_execution) EXCEPT when there are memory barriers (or explicit synchronization instructions). With a multi-core processor things get even more complex, as you have cache locality (a thread reading the point value might be hitting the CPU cache and not main memory). If the thread happens to be executing on a different core than the assigning thread, disaster ensues.

Not sure this is true. There is the concept of final fields, but that doesn't make objects immutable, and thus even when declaring object finals (or arrays) you can pretty easily shoot yourself in the foot by mutating them in-place.

We did this in collaboration with UofC, using our Algo trading platform (http://www.optionscity.com/event/uchicago-midwest-trading-co...) and it was really fun.

Hm, I wonder if there is an interest to make this a more open event :)

Yes, it is interesting, when you are becoming highly concurrent the penalty for context switching start taking its toll, but that's only when the rest of your trading system is already optimized.

OptionsCity - Chicago, IL - Developer

OptionsCity creates professional Options trading software that interacts with the Chicago / NY Exchanges (CME, CBOE, LIFFE, NYSE). We need a Developer to help us get things done (we have a long to-do list and a bunch of features in the queue, and not enough people :).

The position is entry level (Junior Developer / Graduate), so as requirements we don't expect you to know a lot (Our stack for the curious is J2SE, SVN, Hibernate, MySql). The only two real big requirements are to be smart, and work with constraints. These two requirements are much better defined at our site http://www.optionscity.com/jobs/developer.htm (and yes, we decided to go with the maritime themed job posting!)

Thanks!

Freddy

Hm, interesting. It might be very functional, but this really answers questions like, "What source control software you used in your past three jobs", or allows you to compare side-by-side what technology/language you used across jobs. I do find that the format helps me answer those questions I usually have when reviewing resumes. It might not be as skim-friendly (it's packed to the gills with info), but don't find it particularly obtuse; maybe not as 'pretty' or breathable and it's definitively not traditional (wonder if that is what makes it look uglier)

The more I think about it, self evaluating is hard without a reference to "guide" you towards a particular domain. For example, aside from the foundations (name your variables properly, writing readable code), the rest starts going into too esoteric requirements (writing libraries that simplify an api?, author of a framework?). Some of these requirements are unjudgeable (I can author a framework to encode/decode ssl packets, but in itself it's a poor indication of my skill), now writing a framework that stands the test of time (is rarely revised) is a different measuring stick, but that can only be 'evaluated' by someone who understands what are the pitfalls of writing a framework (http://lcsd05.cs.tamu.edu/slides/keynote.pdf). And if you are in an area that writing frameworks is not desirable (a lot of security-centric projects are like that, you want to use trusted sources and not venture in writing your own thing), then that measure becomes irrelevant.

I think that there is only two ways to improve in our field.

- Write, write, and write code. The more complex the better. Two caveats:

Maintain what you write. One-off projects don't count, you gotta live with what you write, since that's forcing you to make it maintainable.

Write with people, if other people have to live with what you write, they will tell you if something stinks (of course this is assuming your teammates have a decent level of professionalism).

- Be mentored: Essentially someone who did the above, and then shows you how he suffered :)

Hope this helps.

Freddy (http://www.javapubhouse.com)

Optionscity Software, Chicago, IL (No Remote) Looking for Senior Java Developer, if you're really all that, then try answering this question!(http://www.optionscity.com/jobs/senior/)

Optionscity Software: Chicago, IL http://www.optionscity.com/jobs/seniordeveloper.htm

Looking for Java J2SE Senior Developer for financial app working on rules engine (Sorry, no telecommute)