rickmode

It was, like, totally there all along. Am I right?

Yes. Otherwise the only way to verify an anti malware system is working is with something actually malicious. So, you know, that's a bad plan. Think of system administrators deploying and validating a security package.

One just needs to be aware that nested sets eventually hit a limit.

I experimented with a variation by Vadim Tropashko using something called "Farey fractions" [1]. These represent the intervals as a 2x2 matrix of four integers rather than two floating point values.

The numbers are effectively limited to 32-bit values in the matrix since a multiplication is required (resulting in 64-bit intermediate results).

It was very interesting, but couldn't model a file system hierarchy well. It could roughly 10^32 items in the best case, but a very small number (hundreds) in edge cases.

For example, it maxes out at a depth of 17 with 100 items at each level, or a depth of 34 with 10 items each. This might be fine for modeling some hierarchies, but definitely not a file system. The edge case is if the fraction extends along one edge. So if we have 10 items per level, and add a child at the leftmost edge each time, we create the most costly fractional subdivision. Do this 35 times and you hit an math overflow.

[1] Check out the Chapter 5 and Errata links: http://vadimtropashko.wordpress.com/“sql-design-patterns”-bo...

First, renames and moves require updating all descendants.

Second, the materialized path's length exceeded the database's indexable length limit. (MySQL, the DB in question, has a default index limit of 767 bytes, so only first 767 bytes are indexed.)

There are ways around these issues (like using "UPDATE ... WHERE" rather than using an ORM to walk the tree and update... sigh). We also had other app-specific / design-specific issues too that swamped these issues performance wise.

I'm hopefully we won't need ancestor and descendant queries again in our re-design. But I'm keeping PostgreSQL with its Common Table Expression stuff--the thing that facilities recursive queries--in my back pocket. It's that or use a stored procedure to build the capability by hand.

This.

The project I'm on used materialized paths, which lead to great pain. I investigated nested intervals ... and they could't achieve the tree depths we needed (we were modeling a file system tree).

We are back to adjacency lists (using a parent ID) but redesigned to avoid the need for recursive ancestor and descendant queries.

_But_ the RDBMS doesn't support recursive queries and I've been curious about PostgreSQL's recursive query support. I played with it, but not on a fully loaded database with deep trees of data.

Does PostgreSQL recursive query support work well with deep trees (> 100 levels) on tables with tens of millions or more rows?

I'm believe I'm asking a valid question.

I read the article last night when it came up on /r/skeptic. The author describes a sort of adolescent addiction due to underdeveloped inhibitions of those who having reach their mid-20s. The thesis seems to say that some addictions are situational, like the distinction between a normal situational depression and a clinical depression (one that does not trace to a person's current life situation).

To restate my question: is what the author describes actual an addiction? Perhaps only those addictions that don't resolve themselves are addictions.

So instead of describe the situation as the author does -- some addictions resolve themselves -- perhaps the definition of addiction needs to be refined.

If you grow out of an apparently addictive behavior, doesn't that -- by definition -- mean it was not an addiction?

OK, I know the definition of an addiction is that the behavior is having a significant negative affect, but there must be some notion of lack of control too, I would think.

I know plenty of my friends in college drank quite heavily. Afterward it tapered off. And some of had quite bad grades during that time. But no off us ended up as alcoholics after college. This was 20+ years ago, so one would assume real alcoholism would become apparent in this timeframe.

I believe UAC works well even when a human always hits OK. The point is to make sure a human is there and trying to do something and not some malicious code.

I believe this would only mask the direct sound waves, not the reflections caused by the room. Perhaps masking the direct sound is enough, but maybe not if the reflections have sufficient energy.

Java is old enough that the current best practices recommend using the language and libraries differently than originally intended.

For new developers that want to do more than trivial things in Java, reading "Effective Java" will help you avoid many of the pitfalls in the language.

As an example, the current best practice around exceptions is that checked exceptions were a mistake. Don't use them in new code. For code that must deal with checked exceptions, you can create your own general exception class derived from RuntimeException, then use a try/catch block to throw your own runtime exception that wraps the checked exception. (But do this smartly; for cases like IOException with web stuff, it is sometimes easier to add "throws IOException" to all your related methods than to exhaustively catch and rethrow.)

As a second example, do not use the JDBC library directly. It is very poorly designed and direct usage can very easily lead to resource leaks. Use something like Spring's JDBC templates or roll your own. (I generally find Spring to be a bloated mess, but the JDBC template stuff is very useful.)

But perhaps the best bet is to use a more modern JVM-based language (of which my favorite is Clojure), though use of these alternatives on Android may be problematic.

Indeed. The question isn't whether the surveillance was legal, but rather if the laws allowing it are constitutional.

You may have a point. I did say "in my opinion". ;)

I'm could be jaded from working on Windows apps too long. (I worked on Windows stuff from the 3.1 era through to Windows 2000.)

To me this looks like an example of Apple's craftsmanship in depth where quality and elegance can be seen at multiple levels, from the case to the internal hardware to the OS and its APIs.

Certainly one can find flaws, but compared to a typical Windows machine Apple has more craftsmanship (in my opinion). Windows exhibits more of the "just get it done" utilitarian idea.

Many annotations in Spring are merely markers used during startup to wire things up or generate bytecode on the fly. There is no way to jump to the actual code.

The cables definitely look like training wheels. Even a very slight bit of tension could assist with balance. Of course that assumes the robot has some sort of kinesthetic sense.

Certainly macros can be hard to decipher, however they don't set up this spooky action at a distance, for example a annotation signaling bytecode injection. There's no way to hand-trace through that; the only solution is to learn the library / framework in-depth.

The ActiveRecord example, to me, is an example of "clever". Any code that exhibits "spooky action at a distance" is too clever, in my opinion. When I can't hand trace a method or function and see what's going on, it is too "clever" - or at least it isn't "explicit".

Spring in the Java world does this with it's XML configuration and code injection based on annotations. You can't decipher what's going on by code examination. To code in Spring you have to fully understand the Spring framework. Rails (to me at least) is similar. The steep learning curve makes them less hackable.

With Clojure, by contrast, you can always look at a function or macro and (eventually) grok what's happening.

"It will probably just get worse over the next few decades."

Languages evolve; some of the current "mistakes" will no doubt become new norms. The changes that stick will tend to be those that cause no ambiguity and confusion.

I love the Economist's dry sense of humor (italics are mine):

"That could lead both to cheaper power, and to the burial of many of the pylon-borne power lines that disfigure so much of the rich world's countryside. In a deeper, sense, then, perhaps Edison will have the last laugh, after all."

The only useful thing I got from MBTI and the related training was that different people think and communicate differently; sometimes very differently. People work differently and you can't treat everyone the same; and different people need styles of communication. This was in the midst of leadership training in an organization that had one set of guidelines for performance reviews and promotions.

So like most management training / classes, this insight is fairly obvious but mostly ignored.

This fits with a life lesson I've been internalizing for the last couple years:

For many problems there are many right answers.

More specifically for opinion/work situation articles like this, the argument applies to a particular personality type and/or particular personal situation.

If you're extroverted, then working alone may leave you bored and unfulfilled.

If you in the middle between introverted and extroverted, working alone may work if other parts of your life have personal interaction.

If you are introverted, working alone may be the best possible situation.

I find working from home works well for me, though at times I feel disconnected, out of the loop, and generally not charged up. But most of the time I find it ideal. I'm middle of the road on the introvert/extrovert scale, am easily distractible when bored (ADHD), and get a charge from working with people - but only when I have part of the day to unwind alone.

I also know working entirely alone on a solo project get me nowhere.

But most of this is about my personality, not about software development, working in a large company, or founding a startup.

There are many right answers. My right answer and yours may be the same if we are similar and in the same situation. Otherwise, my advice probably won't help you - and visa versa.

The oppositions opening remarks do not, in fact, refute the motion. Instead of talking about how MBA's benefit the economy as a whole he talks about how MBA's benefit the individuals who obtain an MBA degree.

Sounds about right. Do you have any sources or this or is this what you've seen personally?

I'm surprised by the negative comments here. The idea of shipping a minimum viable product should resonate well with startup-minded folks. I believe PG himself once said if your project will take longer than 3 months to ship, it's too long.

6 months is a good target. It'll keep new projects lean and focused. It should sway the balance of power more to engineering while forcing the business-side / product management to work tightly with engineering... Or force the product managers to take a back seat for the initial release of a project.

I believe you are right that contrast is more important than both gamut and color accuracy, but a higher gamut will make images feel more alive and give them more "pop", especially in the reds and yellows (as the article discusses).

A high contrast ratio helps prevent banding artifacts in dark shades of gray.

A high gamut does the same for color.

With a high contrast display with a low gamut (a display that can't output a very wide range of colors) you might see banding in reds or yellows even. The brain will compensate for lower gamuts but the image will look more washed out. As an example, a color photo in on newspaper is clearly less vibrant than the same image in a glossy magazine or online.

Also, color accuracy and gamut are not necessarily the same thing. The typical human eye can see far wider range of colors - a wider gamut - than is possible in any display or print technology. Displays are a compromise. sRGB is far less than the human eye can see, which is why image editors use the wider ProPhoto RGB or Adobe RGB gamut (color spaces) and then after editing cleverly compress down to sRGB (or for particular applications, the exact color space of a particular printer / paper combination or of a particular display).

Low-gamut means some colors are missing and compressed to colors that can be shown - so the richest red becomes an orangish-red. While inaccurate, this isn't quite the same the same thing color-shifting all colors in an image, such as the yellow-cast you might see with indoor lighting, or blue-cast with outdoor shadows. All displays introduce color-shifting inaccuracies as well. High-gamut displays have a wider color pallet and are generally tuned better at the factory.

I expect high-gamut displays will just "feel" better in the same way retina / high-res displays do.

[edited for clarity]

> My tool of choice for Java is however IntelliJ, which is simply light years ahead of Eclipse (IMHO).

I agree.

Eclipse seems to always become unstable once enough plugins are installed. After a few updates and removals it ends up tipping over regularly. I suspect the underlying OSGi plugin system is a tricky thing to get right.

Intellij IDEA seems to "just work".

That said, I prefer coding in Clojure with Aquamacs but I've yet to get Clojure into a production system.

The class combines no less than 6 concepts / design patterns:

  - Abstract
  - Singleton
  - Proxy
  - Factory
  - Bean
  - Interceptors

It's not just a long name. The class makes sense in the context of this framework. The core problem (as others here point out) is that the Java flavor of OOP makes writing this sort of code idiomatic.

On the upside, you feel really smart once you grok all these concepts simultaneously. After a couple years this you get to brand yourself a "Java Architect".

To be fair, iOS does not have a back button.

So if I understand right, the warping does not affect the "internal" speed of the spaceship in relation of the universe outside of the warp bubble.

Maybe someone much better with maths and physics can answer this: will the 0.1c speed have a noticable relativistic age-slowing effect for the travelers compared to their Earth-bound friends?

I wonder how much of this is over-fitting.

When I see statistical predictions like this I always wonder about the over-fitting problem.