Saturday, December 11, 2021

Example of a PostgreSQL function to convert json string literal to a table.

Was not able to google one up readily, so created this sample:

Hope it might help someone!

Friday, October 22, 2021

TIL: Proxmox "pct create" -rootfs parameter and disk size.

 Got confused by that -rootfs parameter of proxmox when creating a new container with "pct create", so documenting it here.

-rootfs local:2
translates into (when creating container with id 1062, /etc/pve/lxc/1062.conf):
rootfs: local:1062/vm-1062-disk-0.raw,size=2G
so local:2 then stands for the "local" volume and 2GB as a disk size.

Using size=2G sub-parameter led to the size of 1062G, interestingly. Not sure if this is a bug in proxmox (v7.0) or what.

Saturday, December 7, 2019

Ubuntu 18.04 server and ESXI on Intel NUC Hades Canyon.

This post is just to confirm that dual boot Ubuntu 18.04.3 server and ESXI 6.7 U3 on Intel NUC Hades Canyon is possible and to describe some pitfalls/obstacles I had to jump through.

My configuration for the Intel NUC Hades Canyon is Kingston dual ranked 2x16GB + 2xSamsung EVO 670 500GB.

I first thought I'd do it with RAID in BIOS, but both ESXI and Ubuntu server just ignored this option anyway and second, I read that actually it is a good idea to avoid this BIOS RAID option in order to be able to read/use disks after the CPU/board failure.

#1 Installing ubuntu 18.04.3 server on Intel NUC Hades Canyon

I should tell I was a long time user of Digital Ocean, Host Europe and so on - preinstalled Ubuntu server was it for me. Somehow this time I bumped into "live" version of Ubuntu server and started to install it with the outcome of installation not seeing the disks to install Ubuntu, "Unfortunately Probing for devices to install to failed.":


This "problem" was the reason for the part #2 of this post - installing ESXI. I only got to the article above and understanding that I picked the wrong Ubuntu version after I have ESXI successfully installed as a boot option for disk 1.

Here is the image for Ubuntu 18.04.3 "not live" server, just for a reference:


I also ran into Ubuntu 18.04 server installation getting stuck at 66% while running'update-grub':


After killing the offending process, to exit busybox I used:

```
exit
```

and then probably Ctrl+F1

#2 Installing VMWare ESXI Hypervisor

My main problem with ESXI installation was creating a bootable ESXI image on my mac. After a bit of research I was lucky enough to find Unetbootin:


Other than that, ESXI was a breeze to install and use. Btw, I used the "live" version of Ubuntu 18.04.3 server as ESXI ubuntu iso image and it worked just alright, I really liked the ssh from github option when installing.
--------

This concludes my notes on dual boot Ubuntu 18.04.3 and ESXI on Intel NUC Hades Canyon. Machine performance is outstanding, no heat, no noise. Performance of AWS large instance to paid for itself within 45 days from what I read.

Next steps are to study on MAAS, LXD, Juju for the Kubernetes deployment as a target.

Also looking forward the next generation of Intel NUC Canyon, the Ghost one!

Wednesday, February 20, 2019

xCode 10 Swift 4.2 slow autocomplete and compile times. BAD.

At some point I started to have dismal swift autocomplete delays in xCode 10 and slower compile times. Having googled this and that and optimizing what I could I also found into these type of warnings:



My first guess was that longer tuples are causing the problem. I changed this part to use structs, no joy.

One more part in the code gave me another hint:



Looked to me as if just adding up literals via "+" would be tricky for swift compiler's type checking.

Changing everything above to String(format:) resolved the type checking speed.

If you ask on using string interpolation with \() - it didn't solve the problem. Plus I don't like these messy strings when they get longer.

I have no good words for the guys that work on Swift programming language and its design/tools. I don't think this part and types of optimization should really ever bother us, regular devs.

Bad, bad, bad.... I wish I could have loved Swift more. I love the language even if I don't think it is superior that much to Objective-C. Moving to it from Objective C with all new and updated stuff, but this is simply bad.

P.S. You can find a really good digest of Swift compile time optimizations here:

https://github.com/fastred/Optimizing-Swift-Build-Times

Tuesday, January 1, 2019

TIL - Elixir Jason.Encoder - handling optional fields

At some point along my learning road I had a location struct with the following fields:

@derive Jason.Encoder
defstruct latitude: -999, longitude: -999, speed: -1.0, altitude: -1.0, bearing: -1.0

I added one more field:

defstruct latitude: -999, longitude: -999, speed: -1.0, altitude: -1.0, bearing: -1.0, timestamp: 0.0

And my tests for encoding the struct values after reading these older location records from a file started to fail.

Turns out this @derive part is generating the code similar to this:

defimpl Jason.Encoder, for: [Location] do
def encode(%{altitude: _, bearing: _, latitude: _, longitude: _, speed: _, timestamp: _} = value, opts) do
Jason.Encode.map(Map.take(value, [:altitude, :bearing, :latitude, :longitude, :speed, :timestamp]), opts)
end
end

ref: https://hexdocs.pm/jason/Jason.Encoder.html#content

So older records can't be matched by this automatically generated definition. 

Considering that as a part of "support older data with a fallback value for the new field" exercise and based on Jason.Encoder documentation:

1. I removed the @derive Jason.Encoder line to avoid the automatic protocol implementation generation.
2. Provided own implementation that supports the old data stored:

require Jason

defimpl Jason.Encoder, for: [Location] do
# Matches the default implementation of @derive Jason.Encoder
def encode(%{altitude: _, bearing: _, latitude: _, longitude: _, speed: _, timestamp: _} = value, opts) do
Jason.Encode.map(Map.take(value, [:altitude, :bearing, :latitude, :longitude, :speed, :timestamp]), opts)
end
# Support for older data
def encode(%{altitude: _, bearing: _, latitude: _, longitude: _, speed: _} = value, opts) do
Jason.Encode.map(Map.take(value, [:altitude, :bearing, :latitude, :longitude, :speed]), opts)
end
end

This it for my Today I Learnt.

References:
https://github.com/michalmuskala/jason

And as this post started with adding a timestamp field, here you can read on timestamps in Elixir. From the Jason.Encoder author:
https://michal.muskala.eu/2017/02/02/unix-timestamps-in-elixir-1-4.html

Monday, August 14, 2017

Copying comments in Google spreadsheet into a column

Will copy every comment on a cell in a column into a cell next to the source column (the one with the comments):

function commentsToColumn() {
  // find selection (the source comments)
  var workbook = SpreadsheetApp.getActiveSpreadsheet();
  var sheet = workbook.getActiveSheet();
  var source = sheet.getActiveSelection();

  // determine target (the column to the left of the selection)
  var target = source.offset(0, +1);

  // copy comments
  comments = source.getComments();
  target.setValues(comments);
}

If you need more info for usage, please ask in comments :).

Sunday, July 2, 2017

iOS 11 beta 1,2 - NSString sizeWithAttributes - breaking change and potential bug

Edge behavior of [NSString sizeWithAttributes] seems to be changed in iOS 11 beta 1 and 2. When asked for the


float size around 0.0;
    
    NSString *testString = @"Some test string";
    NSString *fontName = @".SFUIText-Semibold";
    
    UIFont *targetFont = [UIFont fontWithName:fontName size:size];
    
    CGSize stringUISize = [testString sizeWithAttributes:@
                           {
                           NSFontAttributeName: targetFont
                           }];

You may get very different from iOS 7- 10 values. Here is the test:



While running it on iOS 7-10, everything converges to zero string UI width:

2017-07-02 10:11:45.996 speedometer[23301:7084973] attempted font size: 1, calculated string width: 12.157471, delta: -12
2017-07-02 10:11:45.997 speedometer[23301:7084973] attempted font size: 0, calculated string width: 4.052490, delta: -4

2017-07-02 10:11:46.005 speedometer[23301:7084973] attempted font size: 0, calculated string width: 0.000000, delta: 0

 while on iOS 11 beta 1 and 2 the same test case is "stuck" on value 97 something on iPhone 6 Plus:

2017-07-02 08:29:07.157511+0200 speedometer[36517:257340] attempted font size: 4, calculated string size: 36.437256, delta: -36
2017-07-02 08:29:07.158646+0200 speedometer[36517:257340] attempted font size: 3, calculated string size: 28.340088, delta: -28
2017-07-02 08:29:07.159723+0200 speedometer[36517:257340] attempted font size: 2, calculated string size: 20.242920, delta: -20
2017-07-02 08:29:07.160738+0200 speedometer[36517:257340] attempted font size: 1, calculated string size: 12.145752, delta: -12
2017-07-02 08:29:07.161953+0200 speedometer[36517:257340] attempted font size: 0, calculated string size: 4.048584, delta: -4
2017-07-02 08:29:07.166740+0200 speedometer[36517:257340] attempted font size: 0, calculated string size: 97.166016, delta: -97
2017-07-02 08:29:07.167756+0200 speedometer[36517:257340] attempted font size: -1, calculated string size: 97.166016, delta: -97

2017-07-02 08:29:07.168736+0200 speedometer[36517:257340] attempted font size: -2, calculated string size: 97.166016, delta: -97

Looks to me as a broken "contract" and invariant. One would really expect the consistent behavior as it was since iOS7 and having the width of the string calculated as zero for zero font size and zero it should be downwards? Also string width jumping from about approaching zero values to 97.166016 when value got a bit on below zero looks inconsistent. Probably a missing unit test :)!

For me it looks like a bug and I'm reporting it to Apple now. Hopefully it will be fixed to the same consistent behavior as it used to be on iOS 7 - 10.

Defensive coding is like an alloc/release for me, I try to make it right and upfront, but doing static analysis later I found myself being "mentally away" way too often.

Yours and wishing you happy coding!
Stan.