by Bozho | Jan 7, 2012 | Aggregated, Developer tips
Recently I noticed that posts to facebook that I make through my tool (welshare) appear collapsed, with a weirdly big logo, as if it was posted to the app page, rather than through that app (indicated by a small icon) – see screenshot. I immediately reported a bug to facebook, but after I provided the screenshot there was no further action from their side. Then I realized my tweetdeck posts don’t behave the same way. I tried hootsuite – same as tweetdeck – they appear properly in the stream, and without any indication of the source in the timeline. The reason appeared to be simple to fix, but weird. I’ve been sending the post with the “actions” parameter. That means I had an extra link after “comment” and “like”. It was “share” for links (facebook didn’t have it for 3rd-party links before) and “@username on welshare” for text messages. It appears that the post is treated very differently if it contains this parameter. Unfortunately, currently the same behaviour is seen for links and videos, although they don’t contain that param. I hope facebook fixes it, but before that – don’t send that parameter. Another thing they might want to fix: the timeline isn’t showing an icon for the app. This is not necessarily a problem, but indicating the source might be good. Recently I noticed that posts to facebook that I make through my tool (welshare) appear collapsed, with a weirdly big logo, as if it was posted to the app page, rather than through that app (indicated by a small icon) – see screenshot. I immediately reported a...
by Bozho | Jan 3, 2012 | Aggregated, Opinions
Java is too verbose, they say. You can find comparisons of Hello World programs that take 2 lines in ruby and 10 lines in Java, and in order to read a file you need 20 lines in Java and just 1 in php. Even though the examples are often exaggerated (for example counting imports), it is true Java programs requires more lines of code. But this is not a bad thing at all. On the contrary – it is something I actually like. In fact, it is not about the verbosity of the language – apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about. It is about the core libraries. So – I like the way the core libraries are written in terms of verbosity. Two examples: take the java.io. package. Reading and writing files, streams, etc. It is a bit hard to graps, and in the beginning you copy-paste long snippets of code to simply read a file. But it forces you to understand the abstraction of streams and readers. Other languages have simply: var contents = readFile("path") Cool, but you are never forced to understand how the I/O management works. What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? You don’t need to answer these questions for a hello world program, but you will need to know about them pretty soon. And the less-verbose languages hide them from you and postpone this “abstraction revelation”. the servlet API. At first it looks to...
by Bozho | Dec 7, 2011 | Aggregated, Developer tips, Opinions
You are working on that fresh project and you see a bad piece of code somewhere. The wrong way to approach it is “nah, that’s someone else’s code, I’m not doing anything about it”, “I don’t have time to fix that – I have other tasks”, “I’ll surely break things if I change this”. The problem is – bad code accumulates. Even if the piece is a small one, it adds up over time and soon enough you have that “big legacy project that was written by some incompetent guys and no one wants to support”. Someone once said that in six months all projects are “legacy”, because they have a lot of accumulated bad code. Or in other words – technical debt. That’s why you should fix it immediately. When you see some piece of crap, or something that’s not exaactly a great practice – fix it. Now. Or it will be too late, because then other code will start depending on that, and new code will follow the same practice (sometimes with copy/paste), and fixing it will be a nightmare. Let’s address the wrong statements above: “nah, that’s someone else’s code, I’m not doing anything about it” – so, what? You are in that project, you have the “right” to modify it. If the other person has written their code in a bad way, it might be that they even don’t know it’s bad – so they won’t fix it. And I don’t think they will get offended if you fix it. They might, but that’s not your problem. “I don’t have time to fix that –...
by Bozho | Nov 23, 2011 | Aggregated, Opinions
You should have a default use case (or a small set of them). No matter what are you making – end-user product, public API, protocol spec, etc. The default use case is the most common thing that your users will do with your product. The focus of your product. And after you define your default use case, you must make sure it is the most obvious and easy thing to do. Yes, this sounds like a very obvious and universal thing, but many products fail to recognize that. Here are a few examples of products that do it right: the default use case of google is searching. They make it pretty obvious – you have one text box and one button (well, two actually). It is the most straightforward thing to do with their interface. Of course that is not the only thing that you can do – you can customize your search, customize your language, you can advertise or visit their side-projects. But all these are options at the side of the screen. The default use case has all the focus the default use case of Amazon is purchasing. Do they make it obvious? Yes – you pick your items and you click the 1-click checkout button. Extremely simple. And the most obvious thing to do. Of course you can customize all the steps in your purchase, you can be a seller yourself or you can write reviews to items, but these are “side-options” that are available if you look for them. But you immediately see the default use case, and it is the easiest thing to do...
by Bozho | Nov 18, 2011 | Aggregated, Developer tips
They say developing Java is slow because of the bloated application servers – you have to redeploy the application to see your changes. While PHP, Python, etc. scripting languages, allow you to “save & refresh”. This quora question summarizes that “myth”. Yup, it’s a myth. You can use “save & refresh” in java web applications as well. The JVM has the so-called HotSwap – replacing classes at runtime. So you just have to start the server in debug mode (the hotswap feature is available in debug mode) and copy the class files. With eclipse that can be done in (at least) two ways: WTP – configure the “Deployment Assembly” to send compiled classes to WEB-INF/classes FileSync plugin for eclipse – configure it to send your compiled classes to an absolute path (where your tomcat lives) I’ve made a more extensive description of how to use them in this stackoverflow answer. Now, of course, there’s a catch. You can’t swap structural changes. If you add a new class, new method, change the method arguments, add fields, add annotations, these can’t be swapped at runtime. But “save & refresh” usually involves simply changing a line within a method. Structural changes are more rare, and in some cases mean the whole application has to be re-initialized anyway. You can’t hotswap configuration as well – your application is usually configured in some (.xml) file, so if you change it, you’d have to redeploy. But that, again, seems quite an ordinary scenario – your app can’t just load its bootstrapping configuration while running. Even more common is the case with html & css changes....
Recent Comments