Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

Last week I received the Samsung H890 34" Curved Screen Monitor for my home office. The main reason I wanted to get this particular monitor was because it had a USB-C connection and even though it was not advertised as Mac compatible, there was no reason why it wouldn't work with a MacBook Pro. So lets see how I got it all set up...

The box that the monitor arrived in was pretty unspectacular, it was sturdy, well packed and just right for the job. The usual foam packing was inside, curved appropriately to suit the screen panel of course.

DSC03726.JPG DSC03727.JPG

Under the screen panel's lower foam support were the remainder of the included items - stand parts, cable cover and accessory box (mostly cables). It was a little odd how these other parts were packaged, but it worked.

DSC03728.JPG DSC03729.JPG

The immediate difference I noticed to my previous curved screen monitor was how curvy the panel on this monitor was. The curve radius was quite pronounced. I was a bit worried at first about this but now that I've used the monitor for a few days it feels completely natural.

Continue reading...  

, , , ,

I use Silex in conjunction with Backbone.js for one of my personal projects (AtariGamer.com). Both of the frameworks are great and work very well together and are generally very well documented. However, they don't prevent silly mistakes from creeping into your code. This was one of them.

The issue I was seeing was that when I was calling Model.destroy() the error callback was being invoked every single time even on successful deletes. I confirmed that I was in fact getting a DELETE request on the Silex end, and that the deletion was being processed successfully. I figured that since the framework was doing everything right, I must have been doing something wrong.

After a bit of investigation I tracked down and fixed the issue. The problem was with the function that was handling the DELETE request. Specifically it was with the Response object it was returning. The original return statement looked like this...
return new Response('', Response::HTTP_OK);

In hindsight the issue should have been obvious immediately. The HTTP_OK (200) code has this requirement:
Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 No Content instead.

Continue reading...  

, , , , ,

We recently switched from Cobertura to JaCoCo as the test code coverage tool for our services. After some initial troubles with Powermock the tests were running OK and coverage results were coming back as expected. The numbers looked good too. That was the end of that in terms of official tasks that needed to be done for this switch but I was still curious about any performance or coverage differences between the two tools, so I dug a little deeper...

I reverted to the old Cobertura configuration for Maven and ran some builds with test code coverage enabled. I also ran the same tests with the new JaCoCo configuration. The numbers surprised me!

For these tests I disabled Cobertura's report aggregation since that's not being done with JaCoCo. Both tools were generating HTML and XML reports. JaCoCo was set up with offline instrumentation to ensure that Powermock enabled tests were picked up.

These were the times...
 JaCoCo Timing
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:03 min
[INFO] Finished at: 2018-03-06T17:15:37+11:00
[INFO] Final Memory: 74M/768M
[INFO] ------------------------------------------------------------------------
real 1m4.946s
user 4m32.879s
sys 0m27.311s

 Cobertura Timing
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:48 min
[INFO] Finished at: 2018-03-06T17:39:25+11:00
[INFO] Final Memory: 75M/792M
[INFO] ------------------------------------------------------------------------
real 2m49.742s
user 10m33.524s
sys 1m3.292s

That's quite the difference! Cobertura covered builds were taking more than twice the time to complete! This was not something I paid much attention to while we were still using that tool. On slower machines (not everyone uses a 2.9Ghz Core i7 Mac with 16Gb of RAM) this difference in time would be even more profound.

Continue reading...  

, , ,

The Gundam Barbatos along with the Gundam, Zaku II and Z'Gok models in the ICONX lineup are relatively new additions to the model kits offered by Fascinations/Metal Earth 3D. I was excited when I received this kit a few weeks ago and after many hours working on it, was finally able to complete it. The kit was the most difficult Metal Earth 3D kit I've put together but I enjoyed every moment of it.

From start to finish it took me around 10 hours to complete this kit, over 6 separate sessions. The end result was quite breathtaking and really spoke for itself...

Unlike the previous kit I put together, the Guardians of the Galaxy Groot, I didn't have any reservations about the Gundam Barbatos - I loved it even before having it fully assembled.

When the kit arrived, I knew there'd be something different about it...it came in a parcel, not a flat envelope. This was because the packaging was not flat like a typical Metal Earth 3D kit. There was quite a bit crammed inside the box! Compared to the Groot, this kit was massive!

DSC03624.JPG DSC03627.JPG

Continue reading...  

, , ,