BOOM! The particular method I needed to call throws an exception “java.rmi.UnmarshalException: unrecognized method hash: method not supported by remote object”. Googling tells me that this usually means that different classes are deployed on the client and server, so I spend the next half an hour making sure that the JAR on the client and server is exactly the same. A complicating condition is that this particular method returns an object from a third-party library, and to avoid conflicts with the user code we rename the package of that library using JarJar.

As I establish beyond reasonable or unreasonable doubt that the JAR really is the same I start looking into other potential issues. As the exception reports the hash to be missing I start looking into how the hash is calculated for the RMI calls. A fair amount of debugger stepping (a useful tip is that you can put a method breakpoint even if you don’t have the code) reveals that sun.rmi.server.Util.computeMethodHash() calculates the hash using the digest of the method name and signature. Not much room for mistakes there, but nevertheless I put a method breakpoint on UnicastServerRef.dispatch(), which is the last call in the stack trace and dump hashes for all methods in the target class from a static map.

Next I make sure that the hashes are the same on client and server. Decompiling the RMI Stub shows that it includes the precalculated hashes in the call. First check on a different method that I know to work shows that the hashes are the same. But the hash for the problematic method is different in the Stub than in the server map. WTF is wrong?

Here I probably should have verified the next assumptions, but luckily an epiphany interferes. Turns out that the rmic compiler is called before the third-party library is renamed, so the hash is calculated with the wrong packages in the signature. As the JarJar will then rename the signature in the Stub class, it is almost impossible to notice. However the last remaining question is why the hell did it work at all? The hashes should have been different all the time, not just in the vanilla build. A little digging reveals, that as Proguard commonly renames the classes in RMI signatures it will go and fix the RMI hash for you.

EOF

Furious as we were, we managed to keep our manners and reached out (tried to at least) to the author of of jbrute.info and their hosting provider. Sadly, the only response we ever had other than SMTP MAIL CANNOT BE DELIVERED is a canned email instructing us how to write a formal DMCA takedown notice.

We then turned to starting a blog post and asking your help on what you would do in our shoes. As Karl Marx would put it, “the power of the people is strong”, and before long the community came up with a few nothing-less-than-brilliant ideas. (We are not Communists and are not related to the Tsars in anyway, I promise, even though our operational base in Central Estonia might lead you to think otherwise :P)

In particular, Joe Walnes pointed out that since jbrute.info hotlinks .php files and JavaScript from our website, by “check[ing] the HTTP_REFERER, [we] can conditionally change the contents, and with JavaScript [we] can make the page look however [we] want.”

Sadly, life got busy and almost three months suddenly went by, and this little incident was nearly forgotten. Last week, we stumbled upon JBrute once again… Finally we got around to acting on Joe’s advice and, in the most hackish fashion, decided to take it upon ourselves to deliver a truly custom “DMCA Takedown notice” over two glasses of beer. Here is a screenshot of the finished work :) We encourage you to check out jbrute.info (this time I linked :( ) for yourself.

Just to prove our point, we bring you the pseudo xkcd comic.

I hope you enjoyed our little mischief. We’ll keep you posted on the status of jbrute over the coming days following this post and we’ll follow up next week with the technical details – How to un-hack a website! Keep tuned :)

UEsDBBQAAAAIAIVyUjx/yWgsbQIAAP0CAAAHABwAcHJvYmxlbVVUCQADeTB9S3ow
fUt1eAsAAQToAwAABOgDAAAdUsmumlAA3fcrGtNFX1zABblgXm2jOACXSRBEY9Jc
5knmSb6+vi7OkJyzO+fXnx8T6W4WrB3LbiuOBxXMfNRNW8Wn9NipMa4QbVv8MQVL
05STYRfqADEysKpWFm/3mViqu5EtXlzGPVl6zauMly7vUNt3S9ji1LESwdn63jCN
DZkNHrzCc78lb8/mucZtFFM45ckrs1XnmtOYo34WENfnXkzC9vQ6s3sJEpCifalp
BtvFDjI50bJunpHhegTuhAKuKsh49uGhN9tXPJpkNxknpCaHjgoxivp4MNg4YQSG
V+K8IXs3KvSzK2IcaJOxvWny89ztEn66vIpYcNpw1jnkr7CplWUCGGNneZ0Y3mdK
du/0Ss2S8Zqve2ZQWWQcIsDMh/spoPTCEujcunKTWHZ9JZryK6YlAqi7Z+4noaHM
+SC2KyYws6Vk3gqt4FuqESqyfQ6jSjfkIO0yXJgXr6zUI0L6+CKOcmjZvkFyrmxd
92QoKQ0WHcmRqgiKJ7+I6J0xK8d70ALbNBQh8LMlPLlBefMRVfOVkupsao181s+X
alqrQprbp3QH0CuTxEminYhUtGLm8htNsEVWaVvbzxrTTGTuAqlSEbsXQiMdjSCh
SxWaNYe6hknmS6ND+6g01+aoFnZ/qaURCYTRQBEf9vEp9UmrIxTb7bnzMOFzaFE1
cagV4M+WbexrQrDLPf/eqjROlTqeNYFVbwpYLvV+HTgdbcxavlan9ZhtFp/vb3qb
hYsfE0sHcPXXf0yQeYAV/dbQfxvmfyfYLKIHYKkHYMA7Cd6Ab3i4Cxaf34MB5z+/
Wl/kfZH78fHx+ef3t39QSwECHgMUAAAACACFclI8f8loLG0CAAD9AgAABwAYAAAA
AAABAAAApIEAAAAAcHJvYmxlbVVUBQADeTB9S3V4CwABBOgDAAAE6AMAAFBLBQYA
AAAAAQABAE0AAACuAgAAAAA=

Please don’t post the answer in the comments, but you’re welcome to tell what game is the quote from and how long did it take you to solve it.

This is a story of a start-up built around the nerdiest glasses on earth. If you wonder why and how we’re doing it, how exactly will we make millions of dollars off of it then you’re in luck. We’re planning to document and publish everything on our website and we have just released the first in the series, Converting a pair of glasses into fame and fortune.

There are different ways for integration. Usually it is done via an API. The host platform offers some hooks into the system and you can use them to add some custom functionality on top of the host (or maybe just integrate your own product with the host). The result of this in the IDE world is a plugin. JRebel (the product our team is spending the most development time on) has plugins for application servers, frameworks and even IDEs.

If you’re in luck you can achieve everything with the API, if not you need other tricks. If the API does not offer certain public methods or access to some internal fields you can go in with reflection and still use them (of course there are no guarantees if the internals stay the same on version changes).

One step further to the darkside is binary patching. By binary patching I mean adding/changing/removing methods/fields/classes in runtime. This is the approach that we had to take when writing the JRebel NetBeans plugin.

On NetBeans startup we lookup a debugger class and on success try to patch it. In 2009 and using the JVM (not native apps) it is quite an easy task, at least for the most part. No assembler involved (of course you could be using a bytecode generation library), no need to do jumps to correct offsets or even read assembler (or bytecode).

In our case we use the Javassist library. It is a matter of inserting Java code embedded into a String to methods looked up via reflection. For example the following code adds some new code into the beginning of a method.

ctc.getDeclaredMethod("setRequests").insertAfter(
  "org.netbeans.api.debugger.jpda.LineBreakpoint _breakpoint = getBreakpoint();" +
  "java.lang.String _className = _breakpoint.getPreferredClassName();" +
  "if (_className == null) {" +
  "  _className = reader.findCachedClassName(_breakpoint);" +
  "  if (_className == null) {" +
  "    _className = org.netbeans.modules.debugger.jpda.EditorContextBridge.getContext().getClassName (" +
  "      _breakpoint.getURL ()," +
  "      lineNumber);" +
  "    if (_className != null && _className.length() > 0) {" +
  "      reader.storeCachedClassName(_breakpoint, _className);" +
  "    }" +
  "  }" +
  "}"

For the complete source code of the patch see the src folder of the nb-plugin.

In conclusion, the best way to integrate with any system is via the API it provides. If it does not cut it then look into reflection and start using internals. You will lose on maintainability of course. Still not happy? Look into binary patching and have your fingers crossed whenever the target platform releases a new version.

My Eclipse instance starts with a warning popup. Well, most likely it picked up a JRE instead of the usual JDK specified in my environment variables. But hey, I know how to handle property files (ed: seriously?), and they are actually pointing me towards the eclipse.ini.

Clicking the link on the warning popup does not open the file itself though, so I have to manually navigate to the C:\Programs\eclipse folder and find eclipse.ini from there containing:

Adding –vm C:\Program Files\Java\jdk1.6.0_14 to the end of the configuration and restarting. Well – nothing has changed. OK, let’s open up Google.

Proposed solution: -vm option has to be specified before the –vmargs option. Still no help, Eclipse will start with the previously mentioned warning.

Second solution – there has to be a line break between –vm and the value specified – BINGO. We are getting somewhere –

Now let’s just change it to:

And it just works. But for heaven’s sake – why on earth do I have to figure out

• where is the configuration I have to change
• in which order do I have to specify the parameters
• that the key-value options must be separated with the line break

Considering the last warning dialog – why cannot the whole configuration be validated and initialization failed properly? If this were a tool used in-house or only by small number of freaks, then – let it be. But this is Eclipse we are speaking about – there are millions of people working their asses off on a daily bases with this tool. Can’t imagine the time wasted for problems like this …

The talk borrows the title and format from the Mythbuster TV show, where experts recreate the urban legend situations to check if they are plausible or not. Scott confirms or busts one myth at a time using the data from the surveys that come from a variety of sources, some of them more trustworthy, some less.

The reasons I couldn’t take some of the conclusions seriously were:
1) Agile is not well defined. There’s a large number of practices considered Agile, and many people will claim that they’re doing agile e.g. if they have a build server.
2) Surveys only tell what people think is happening. If you want to know how long is the nose of the emperor of China you don’t walk around asking people. Worse a lot of those surveys are conducted only among the Agile or TDD community, which gives them a high bias against traditional development.
3) Comparing Agilists to Traditionalists is like comparing Tide to the Usual Washing Powder. There’s no such thing as a traditional methodology, there’s a bunch of them with very different approaches.

Note that here I give only my interpretation of Scotts talk and data, so please don’t treat it as anything else, but my own opinion.

Myth 1: The majority of organizations are now doing Agile.

Survey shows that 76% of organizations claim they are doing Agile.

CONFIRMED!

Myth 2: The majority of project teams are doing Agile.

In the 76% of the organizations claiming to do Agile only 44% of teams report using it. That translates to roughly 33% of the “popular vote” for Agile. Therefore 66% of developers are not even claiming to do Agile..

BUSTED!

Myth 3: Agile is all about development

In the list of Agile practices the only one that is used by more than half of developers claiming to do Agile is Continuous integration (65%). That kind of underlines the fact

PLAUSIBLE?

Myth 4: Agile is just for small teams

A lot of large projects are confirmed succeeding with Agile. In fact success rate isn’t that different from small ones. Would be interesting to see the breakdown of different practices used in small v/s large projects.

BUSTED!

Myth 5: Agile doesn’t work in a regulatory environment

To clarify here are meant environments where errors are critical and thus are regulated by legal or engineering requirements. Surprisingly 33% are using Agile in a regulatory environment. Again a breakdown of practices would be very interesting as there’s bound to be some difference.

BUSTED!

Myth 6: Agile & CMMI don’t work together.

Only 9% reported using Agile. I think Scott put this as BUSTED, but 9% sounds like CONFIRMED to me :)

Myth 7: Agile approaches are “empirical”.

Very weirdly phrased claim. The survey shown was 51% of respondents collecting manual metrics, 19% collecting automatic metrics and the result was CONFIRMED.

Myth 8: Agile teams are mostly building from scratch.

78% of respondents work with legacy at least on some level. Scott had a pretty interesting digression on how Agile practices handle well the legacy code (with tests, refactoring, etc), but don’t give that much attention to the quality of legacy data.

BUSTED!

Myth 9: Agile certification is a good idea.

78% of respondents think certification is meaningless, wonder how many of them are certified (as does Scott). An interesting digression about a guy having both PhD and Scrum master on his business card, as if their value were the same. Certification that doesn’t require any real effort is greatly overvalued in the community.

However although Scott considers the myth busted, I don’t think it makes sense to ask this question from everyone. If this’d be a poll among hiring managers it would make much more sense.

BUSTED?

Myth 10: Agile teams are colocated.

Survey shows that only 42% are colocated.

BUSTED!

Myth 11: Agile doesn’t do up-front estimates.

In the world of budgets this premiss always sounded ridiculous. And unsurprisingly 89% of teams have to provide an up-front estimate (with different level of certainty).

BUSTED!

Myth 12: Agile teams just start coding.

No kickoff is another thing I never believed. From the data about a month of kickoff is usual before starting the actual coding.

BUSTED!

Myth 13: Agilists follow common dev conventions.

Data is a bit confusing, but seems that 59% have some kind of conventions.

PLAUSIBLE?

Myth 14: Rights & responsibilities are part of the agile culture.

The question is quite weird and the data isn’t really connected to it.

PLAUSIBLE?

Myth 15: Agilists test often and test early.

Only 71% in the TDD community are actually doing TDD. WTF? And agile guys are still having integration tests (45%) and hired testers (36%). This confirms my suspicions that unit tests are not the silver bullet as many suppose them to be.

CONFIRMED!

Myth 16: Agilists don’t do up-front requirements modeling.

76% are doing high-level up-front requirement modeling. This correlates with Myth 11, because to provide reliable estimates you need to have an idea what you’re going to be doing.

BUSTED!

Myth 17: Agilists don’t do up-front architecture.

70% do architecture design. This explains the month of kickoff along with the requirement gathering.

BUSTED!

Myth 18: Agilists write some “interim” docs.

Not sure if anyone doubted it, but 56% agree.

CONFIRMED

Myth 19: Agilists don’t do supporting docs.

The numbers are slightly lower than “Traditionalists”.

BUSTED!

Myth 20: Traditionalists write better docs.

Equally bad at writing docs according to polls. I can believe that :)

BUSTED!

Myth 21: More difficult to add members to Agile projects.

Data shows that it’s slightly easier to add in Agile. Promiscuous pairing makes it even easier, so make sure to be promiscuous.

Frankly I heard the other myth that it’s easy to add members to Agile projects, that is busted as well.

BUSTED!

Myth 22: Agile works better than traditional approaches.

The ultimate question :) Success rate over different approaches:

• Iterative — 71%
• Agile — 70%
• Traditional — 66%
• Ad-hoc — 62%

Personally, I think that the variation is pretty small and it’s more important that 30% of projects fail no matter what than the 4% of difference between Agile and “Traditional”.

However when broken down on specific aspects (like cost, time, quality), it seemed that Agile was considerably better. I’d take it with a grain of salt though, as a lot of people take Agile as a religion and measure success accordingly :)

CONFIRMED?

A spin-off is a new organization or entity formed by a split from a larger one, such as television series based on a pre-existing one, or a new company formed from a university research group or business incubator.

Moving is work, getting stuff into boxes, moving the boxes and getting the stuff out of the boxes. We were able to add a fun factor to the process. The evening before the move our team was having beers at a local bar and one thing lead to another and the next moment we were at the old office with a knife, pillow and 3 eggs and it was 1AM.

So in the middle of the night, at the office, 3 guys with the mentioned equipment and a plan! The plan was simple. Webmedia CEO’s name is Eagle (at least in the Estonian language) and what if we prep his office for a proper leaving. Stage it as birdies leaving the nest, feathers, egg-shells. Awesome plan from just 4 beers!

Pictures follow.

• The sign says ZeroTurnaround guys have left the nest. Thanks!
• Yeah, all the feathers come from a single pillow
• Yes, I’m missing a pillow
• Yes, we had to clean it up (well, just me, because everybody else supposedly had more important tasks at hand).

However now that I know this is a scam, I just might to try and turn the tables on the scammer. If I succeed to do anything fun, I’ll be sure to let you know :D

The letter is verbatim below to serve as a warning to those even less careful than me:

(If you are NOT CEO,please forward this to your CEO, because this is urgent.Thanks.)

Dear CEO,

We are the department of registration service in China. we have something need to confirm with you. We formally received an application on Sep 28, 2009, One Japan company called Seed soft investment Corp” are applying to register(zeroturnaround) as internet brand name and domain names as below (zeroturnaround.net.cn zeroturnaround.org.cn zeroturnaround.mobi zeroturnaround.asia zeroturnaround.in zeroturnaround.hk zeroturnaround.cc zeroturnaround.tw in etc.).

After our initial checking, we found the internet brand name and these domain names being applied are as same as your company’s, so we need to get the confirmation from your company. If the aforesaid company is your business partner or your subsidiary company, please DO NOT reply us, we will approve the application automatically. If you have no any relationship with this company, please contact us within 10 workdays. If out of the deadline, we will approve the application submitted by Seed soft investment Corp” unconditionally.

We would like to get the affirmation of your company,please contact us by telephone or email as soon as possible.

Best Regards,

Kevin Wu
Senior Director
TEL: +86 21 69929440
Fax: +86 21 69929447
Website:www.govqipeng.org.cn
Address:Room 902,8th,nong 1518,Jinyuan 1st Road,Jiading District, Shanghai city.