System.out.println("value: " + Math.abs(Integer.MIN_VALUE));
Try it out yourself! If this makes any kind of damn sense to you please enlighten me in the comments.
In which I post random thoughts about software and things that I think would make good interview questions.
System.out.println("value: " + Math.abs(Integer.MIN_VALUE));
struct Point {Ok, thats nifty, lets do that in javascript:
double x;
double y;
double z;
};
var point = {Correct so far, that is pretty much how you'd do that in javascript. But what you are really doing can be best explained by doing a literal translation of the javascript back into C:
'x':x,
'y':y,
'z':z
}
std::hash_set<std::string, double> point;"If you put this in a code review, first your coworkers would laugh alot, and then they'd make mean jokes about you for the next year."
point["x"] = x;
point["y"] = y;
point["z"] = z;
That's pretty much it and if you are uncertain about what criteria you want to use for deciding when to revisit your team's process, you could do alot worse than to adopt this list.
- Unpredictable. Some efforts become unpredictable. A team says they are going to be done on Friday and miss the date or the team says a feature is working but it isn’t. Unpredictability is often a sign that the work is not fully understood—that the upfront planning was not adequate to begin the task. What contributes to unpredictability is a two-steps forward, one-step back rhythm. Almost always the answer to unpredictability is the need to slow down before speeding up.
- Lots of foundation, not a lot of feature. There’s an old adage that great programmers spend 90% of the time on 10% of the problem (I once interviewed a student who wrote a compiler in a semester project but spent 11 of 12 weeks on the lexical phase). You can overplan the foundation of a project and fail to leave time for the whole point of the foundation. The checkpoint is a great time to take a break and make sure that there is breadth not just depth progress. The luxury of time can often yield more foundation than the project needs.
- Partnerships not coming together. In a project where two different teams are converging on a single goal, the checkpoint is the right time to sanity check their convergence. Since everyone is over-booked you want to make sure that the changes happening on both sides of a partnership are being properly thought through and communicated. It is easy for teams that are heads down to optimize locally and leave another team in a tough spot.
- Unable to make changes. In any project changes need to be made. Surprisingly both ends of the methodology spectrum can make changes difficult. Teams moving at a high velocity have a lot of balls in the air so every new change gets tougher to juggle. Teams that have done a lot of up front work have challenges making changes without going through that process. In any case, if changes need to be made the rigidity of a methodology should not be the obstacle.
- Challenging user experience. User interface is what most people see and judge a product by. It is sometimes very difficult to separate out whether the UI is just not well done from a UI that does not fit well together.
- Throwing out code. If you find you’re throwing out a lot of code you probably want to step back—it might be good or it might be a sign that some better alignment is needed. We’re all aware that the neat part of software is the rapid pace at which you can start, start over, iterate, and so on. At some point this “activity” fails to yield “progress”. If you find all or parts of your project are throwing out more code, particularly in the same part/area of a project then it is a good time to check the methodology. Are the goals clear? Is there enough knowledge of the outcome or constraints?
- Missing the market. The biggest criticism of any “long” project schedule is the potential to miss the market. You might be heads down executing when all of a sudden things change relative to the competition or a new product entry. You can also be caught iterating rapidly in one direction and find competition in another. The methodology used doesn’t prevent either case but a checkpoint offers you a chance to course correct.
Merger merger = [[Merger alloc] initWithFirstString:"foo" andSecondString:"Bar" startingAt:1 suffleOutput:false lowercaseOutput:true];If you wanted to write that in java, it would be fairly incomprehensible:
Merger merger = new Merger("foo", "Bar", 1, false, true);
Merger merger = new Merger(); merger.setFirstString("foo"); ...
${:import(com.google.common.base.Preconditions)} public static ${enclosing_type}Builder Builder() { return new ${enclosing_type}Builder(); } public static class ${enclosing_type}Builder { private String property = null; @SuppressWarnings("synthetic-access") public ${enclosing_type} build() { Preconditions.checkState(this.property != null, "property is required."); return new ${enclosing_type}(this.property); } public ${enclosing_type}Builder property( final String property) { this.property = property; return this; } }
By convincing a user to visit a specially crafted HTML document, a remote attacker may be able to execute arbitrary code on a vulnerable system.http://thenextweb.com/insider/2013/01/10/new-java-vulnerability-is-being-exploited-in-the-wild-disabling-java-is-currently-your-only-option/
my resume, according to Tagxedo |
A Kindle SDE Job Description |
write once, sorta runs everywhere |