by Bozho | Oct 6, 2014 | Aggregated, Opinions
The other day I gave a talk on a tech conference about my experience with Scala. Ironically, just two weeks after I wrote that I don’t like Scala, I started working with it on a daily basis, so I now have a better overview. And it’s not all black and white, but many of my arguments still hold. You can check the slides (the talk was not in English). And I’d like to emphasize the final conclusion point: don’t give the users of your language, API or product all the possible options – they will misuse them. The other day I gave a talk on a tech conference about my experience with Scala. Ironically, just two weeks after I wrote that I don’t like Scala, I started working with it on a daily basis, so I now have a better overview. And it’s not all black and white, but many of my arguments still hold. You can check the slides (the talk was not in English). And I’d like to emphasize the final conclusion point: don’t give the users of your language, API or product all the possible options – they will misuse...
by Bozho | Sep 18, 2014 | Aggregated, Developer tips
Load-testing is not trivial. It’s often not just about downloading JMeter or Gatling, recording some scenarios and then running them. Well, it might be just that, but you are lucky if it is. And what may sound like “Captain Obvious speaking”, it’s good to be reminded of some things that can potentially waste time. So, when you run the tests, eventually you will hit a bottleneck, and then you’ll have to figure out where it is. It can be: client bottleneck – if your load-testing tool uses HttpURLConnection, the number of requests sent by the client is quite limited. You have to start from that and make sure enough requests are leaving your load-testing machine(s) network bottlenecks – check if your outbound connection allows the desired number of requests to reach the server server machine bottleneck – check the number of open files that your (most probably) linux server allows. For example, if the default is 1024, then you can have at most 1024 concurrent connections. So increase that (limits.conf) application server bottleneck – if the thread pool that handles requests is too low, requests may be kept waiting. If some other tiny configuration switch (e.g. whether to use NIO, which is worth a separate article) has the wrong value, that may reduce performance. You’d have to be familiar with the performance-related configurations of your server. database bottlenecks – check the CPU usage and response times of your database to see if it’s not the one slowing the requests. Misconfiguring your database, or having too small/few DB servers, can obviously be a bottleneck application bottleneck – these you’d have...
by Bozho | Sep 11, 2014 | Aggregated, Developer tips
Several months ago I created the EasyCamera project (GitHub). As there has been a lot of interest, I just released it to Maven central, so that you don’t need to checkout & build it yourself. The packaging is also changed to aar now. I would appreciate all reported issues and feedback about the API. Let me just remind the usage: EasyCamera camera = DefaultEasyCamera.open(); CameraActions actions = camera.startPreview(surface); PictureCallback callback = new PictureCallback() { public void onPictureTaken(byte[] data, CameraActions actions) { // store picture } } actions.takePicture(Callbacks.create().withJpegCallback(callback)) I won’t paste the code that you would normally have to write, but you should follow 10 steps, and I believe the EasyCamera API is a bit friendlier, easier to discover and harder to misuse. Several months ago I created the EasyCamera project (GitHub). As there has been a lot of interest, I just released it to Maven central, so that you don’t need to checkout & build it yourself. The packaging is also changed to aar now. I would appreciate all reported issues and feedback about the API. Let me just remind the usage: EasyCamera camera = DefaultEasyCamera.open(); CameraActions actions = camera.startPreview(surface); PictureCallback callback = new PictureCallback() { public void onPictureTaken(byte[] data, CameraActions actions) { // store picture } } actions.takePicture(Callbacks.create().withJpegCallback(callback)) I won’t paste the code that you would normally have to write, but you should follow 10 steps, and I believe the EasyCamera API is a bit friendlier, easier to discover and harder to...
by Bozho | Sep 7, 2014 | Aggregated, Opinions
We all know the C-major scale: do-re-mi-fa-sol-la-ti-do. But what’s behind it? And how many other scales there are? It’s complicated. Let me do a brief introduction into the theory first, without trying to be precise or complete. In use are more than a dozen scales, and the popular one in the western world are the major, minor (natural, harmonic), and the “old modes”: Dorian, Lydian, Locrian, etc. All these are heptatonic (7-tone) scales. There are also pentatonic (5-tone) scales, and also other scales like Turkish, Indian, Arabic. All of them share a common purpose: to constraint melodies in order to make them sound pleasant. The notes in each scale trigger a different level of consonance with each other, which in turn provides different “feel”. The predominant scales all fall within the so called chromatic scale, which consists of all the 12 note octave on a piano keyboard (counting both white and black keys). How are the scales derived? There are two main aspects: the harmonic series and temperament. The harmonic series (closely related to the concept of an overtone) are derived from the physical behaviour of the musical instruments, and more precisely – oscillation (e.g. of a string). The harmonic (or overtone) series produce ever-increasing pitches, which are then transposed into a single octave (the pitch space between the fundamental frequency and 2 times that frequency). This is roughly how the chromatic scale is obtained. Then there is temperament – although the entirely physical explanation sounds a perfect way to link nature and music, in practice the thus obtained frequencies are not practical to play on musical instruments, and...
by Bozho | Sep 5, 2014 | Aggregated, Developer tips
Does this piece of code look ok to you? HttpURLConnection connection = null; try { connection = (HttpURLConnection) url.openConnection(); try (InputStream in = url.getInputStream()) { return streamToString(in); } } finally { if (connection != null) connection.disconnect(); } Looks good – it opens a connection, reads from it, closes the input stream, releases the connection, and that’s it. But while running some performance tests, and trying to figure out a bottleneck issue, we found out that disconnect() is not as benign as it seems – when we stopped disconnecting our connections, there were twice as many outgoing connections. Here’s the javadoc: Indicates that other requests to the server are unlikely in the near future. Calling disconnect() should not imply that this HttpURLConnection instance can be reused for other requests. And on the class itslef: Calling the disconnect() method may close the underlying socket if a persistent connection is otherwise idle at that time. This is still unclear, but gives us a hint that there’s something more. After reading a couple of stackoverflow and java.net answers (1, 2, 3, 4) and also the android documentation of the same class, which is actually different from the Oracle implementation, it turns out that .disconnect() actually closes (or may close, in the case of android) the underlying socket. Then we can find this bit of documentation (it is linked in the javadoc, but it’s not immediately obvious that it matters when calling disconnect), which gives us the whole picture: The keep.alive property (default: true) indicates that sockets can be reused by subsequent requests. That works by leaving the connection to the server (which supports...
Recent Comments