Making pixel art has never been a hobby of mine until I stumbled upon 8bit Painter for Android. This app is a bitmap editor with very few features and a lot of constraints – however, this also makes it easy to use on a handheld device such as my Galaxy S5 phone.
Features more or less are:
Gallery list with all images made in the app.
Grid with each cell representing a single pixel.
Pan and Zoom
Fixed canvas sizes from 16 x 16 to 128 x 128, nothing customization here.
Ereaser, Pen, Fill and Picker tools.
Colorpicker with presets, brightness and saturation support.
Export to e.g. Google drive
Its an awesome app to use when idling with ones phone, e.g. in a meeting without an interesting agenda 🙂
I have tracked my daily weight and exercise since 2016. The primary motivation: I wanted to loss a bit of body mass and to do so it would be beneficial to track my progress.
The secondary motivation: I want to statistically calculate if my weight loss is primary due to exercising. This was my initial hypothesis since my weight fell dramatically after I began my exercising. Alas I could not keep the fast decline after a few months, and my new hypothesis is that exercise not the primary factor for weight loss in my case.
This also makes perfect sense, since it is very easy to eat too much during the day which is near to impossible to burn in the evening with the one-two hours of spare time. What does the data say?
For each day since 2016 I have an entry of current weight (measured in the morning) + how much exercise I got for the day. Typically, this is how much I rode my training bike in the evening. My initial hypothesis was that more exercise leads to more weight loss, but not necessarily the day after, i.e. training for 60 min one does not result in weight loss the next day but a few days after.
To simplify my data-set I summed all the daily values into weekly values and converted the weight into a weight changes, i.e. the delta between the first measure weight next week minus the weight on the first day of the week. My hypothesis was that there was a negative co-variance between exercise time and weight change, i.e. negative weight change with increasing exercise time.
As seen on the scatter plot, there is indeed a correlation between between exercise time (x-axis) and weight change (y-axis) and it is negative. It is far from perfect though, at does not explain that much. CORREL states that exercise time explains only 30% of the weight change, so 70% of the weight change is not explained by the data that I have collected.
Looking at the data it is clear that increasing exercise helps with weight loss. Getting 100-150 min of exercise during a week seems to be a reasonable choice to maximize weight loss. Beyond this the weight loss decreases in magnitude which I cannot explain.
Getting less than 50 min but more than 0 min of exercise every weeks clearly shows a negative weight loss trend, while getting 0 min of exercise shows a smaller weight gain.
Conclusion: it is important to exercise at-least 120 min a week while keeping in mind that exercise is not the primary factor for weight loss (only 30%).
I started this blog 1 year age. The motivation was 100% for fun and to see how many visitors and view I could get without any niche. I made roughly 64 posts (nice round number) spanning different topics, primarily programming related.
The stats of 2017 are shown here:
According to the stats I got about 500 views (41/month) and 250 visitors (20/month). Not anything to brag about and nowhere near the 100,000 views / month required to earn a decent amount of money on ads.
To increase the number of views, it is clearly required that one
Clearly defines a niche! not just any-topic as I have done.
Exposes the content through social media or other sites.
Improves the look and feel.
Self-hosts – using .wordpress.com looks a bit cheap.
Learn to write better.
Although I believe I have improved on the last point – I am nowhere near a blogging expert.
I really need to level up my game if I want to increase the number of views.
So for 2018, my goal is to see if I can reach 1000 views and 500 visitors.
I recently encountered a problem with one of my many Azure services. The service in question provides an API to download files from a Azure file share; this worked perfectly on some endpoints but not on others.
It took me a while to nail the issue which was due to a violation of MinResponseData rate limit in Kestrel. On endpoints with a stable Internet connection, everything was OK, but on others were the Internet connection was less stable the download frequently failed.
Even if the endpoint had OK bandwidth, the download would still fail since the connection might be gone for a few seconds. According to the docs:
Defaults to 240 bytes/second with a 5 second grace period.
Lakka supports Raspberry Pi 3 and I wanted to see if it was indeed powerfull enough to run SNES and N64 emulation.
I flashed a Microsd with the latest Lakka image and tested the setup using my 42″ Panasonic Plasma. First impressions were very bad, Super Mario World was choppy and the sound was glitchy.
Changing resolution of retro-arch from 1920×1080 to 1280×720 helped a bit, but still the performance was not acceptable. I tried with vsync off and on, but the performance still seemed bad.
After tweaking a bit, I noticed that the FPS was locked at 50 when inside the menu. It seemed my TV was running 50Hz and not 60Hz. The Super Mario World rom was the NTSC version, i.e. 59.99Hz version, which ofcourse meant that 50Hz would feel bad.
I connected with SSH and using tvservice to see what my output was. Indeed, 1920x1080x50hz was my output!! What the hell…
Luckily, this can be changed within the config.txt file residing in /flash. (Remember to remount flash with write permissions since it is readonly by default)
Adding the following lines to config.txt fixed my issue:
the lines above configures the output to be HDMI with audio with a specific mode. Mode defines the resolution and refresh-rate, e.g. mode 16 is 1920x1080x60hz while mode 31 is 1920x1080x50hz. Mode 31 was selected by default in my setup apparently.
For my latest project I required about 50 x 250px x 250px charts on one page. Initially, I used Recharts because it looks freaking great and integrates nicely with React.
I quickly realized however that Recharts does not scale well because it is DOM heavy. For my applicaiton I quickly reached 12,000 DOM nodes. Loading performance is pretty bad when so many DOM elements needs to be initialized – however, the performance when initialized is actually OK.
In any case, I replaced Recharts with Chart.JS and saw a big performance improvement. My DOM nodes were reduced from 12,000 nodes to about 2000 nodes. Loading time was substantially improved and the performance of the application feels much better.
The biggest difference between the two charting components isthat Recharts is implemented using SVG elements while Chart.JS is implemented using a 2D canvas. The canvas only requires a single DOM node, while SVG requires several DOM nodes for data, chart configuration, etc.
In any case, for chart heavy applications with many charts, Chart.JS is my charting component of choice.
The lib does not feel natural but I do like that I know that memory management performance will not explode in my face when using it.
Creating a 2D vector is done explicitly by writing
let v = vec2.create();
while adding vectors together is done by
vec2.add(out, v1, v2);
operations such as add, sub, etc. do not enfer any memory allocation what so ever, making the operations fast and without garbage collection at a later time.
The API does feel very ‘C’ like. I really miss the ability of .NET where one can allocate to the stack by using Structs.