My go to IDE of choice is Netbeans, but today I tried out Zed. This is because Snap has managed to break Netbeans, and I’m blown if I can figure out what they’ve done to it.

Installing Zed

Zed was easy and quick to install. A quick line of bash and I was up and running in moments, which beats the heck out of putting up with Ubuntu’s weird and broken Snap sandboxing thing.

What did I like about Zed?

Zed is light and zippy fast.

What PHP support it has was a breeze to install.

Zed’s code colouring was intuitive but took a little getting used to. Once over the initial unfamiliarity bump, I grew to like it. I especially appreciated that class variables inside methods were coloured differently (red) to methods and local variables.

Zed makes no attempt to write my code for me.

The UI is minimal, which is fine if you like keyboard shortcuts.

What did I dislike about Zed?

I missed NetBeans’ concept of a “project” for grouping and navigating files.

Unlike NetBeans, Zed does not offer autocomplete outside of methods and variables defined in the code. I’ve gotten used to having PHP’s built-in functions not only offer to autocomplete but comes complete with documentation too. Given how inconsistent PHP can be, this is kind of essential.

On save, Zed enforces the aligned braces style code. I know this is supposed to be the standard, but I have never been a fan of the style, nor of IDEs that think they know better than me.

I missed NetBeans’ autocompleting documentation comments (and the way Netbeans shows you documentation comments in the auto-suggest).

I’m not sure Zed does autosave.

There was no obvious way to resize the code font. Admittedly, I only tried the usual Ctrl plus Mouse Wheel.

Despite my comments about Smart-Alick IDEs, I really appreciate NetBeans’ way of flagging possibly mistyped or malformed code. Zed doesn’t do that.

I very much missed NetBeans’ template and default system. Zed feels more like a text editor than an IDE in that way.

Would I use Zed?

As a quick backup – maybe. For my daily driver – hell no. I prefer an IDE that does a little more heavy lifting rather than something that feels like a slightly upgraded Notepad++.

Get Zed

You can get Zed here.

Over to you?

Have you used Zed or do you perhaps currently use Zed? Do you think I’m way off, have missed something, and need to give it another go? Or, perhaps, you agree with me. Or something else? Let me know by reply, comment, or mention your thoughts on Zed as for code dev.

So, last night I slept for a very long time. While I slept, I dreamed that I was explaining to a scientist how to do real random number generation with a computer chip. And, you know what, I think it would actually work.

Computers are not good at randomness

The only thing that computers are good at is giving you the same output for any given input each and every time. It is their predictability that makes them so darn useful.

This is a problem when what you need is randomness.

The closest we have to computer-generated randomness is algorithms that give outputs that are hard for humans to guess. The thing is, for any given seed value, you still get the same output. That’s why Minecraft seeds are a thing.

One of the better algorithms is the Mersenne Twister. This is what powers mt_rand() in PHP.

Nevertheless, this sort of randomness is only pseudorandom. Accidentally use the same input, get the same output.

How can we do better?

One of the best ways to generate cryptographically secure randomness is to use some large external source of chaos. For example, Lavarand. Lavarand is powered by a wall of lava lamps, which the system takes photos of at intervals. The system then extracts some amount of the binary of the image, interprets it however the designers want (all things in computers are just binary, and we only know what sort of thing they are by leaving hints). This data is then used as the seed for pseudorandom generation.

The inclusion of a pseudorandom step means that although the randomness is pretty good in terms of being unguessable, it is still not truly random.

My answer to truly random numbers from a computer

We start with a 64-bit quantum chip. Quantum computing is different from the computing we know now. QBits sit between 1 and 0 until they are read. This allows for some very specific types of computation at speeds that we cannot currently reach with classical computing.

Qbits – quantum bits – suffer from a significant weakness. They are so tiny that a single photon can flip them. Rather than fight this data damage, we can harness it.

We choose 64 because qbits are a bit tricky to make at scale, and 64 bits is what our regular computers use. You could go for a bigger size, say 128, 256, 512, 1024, etc., for cryptographic uses.

One way would be to give the top of the chip a convex glass “lid” that encuredges light into the chip. Another would be to add a layer of tritium and a phosphor, which would glow and send off photons. You could also use some other radioactive matter as long as it gives off something that can flip a bit.

All of these flips are entirely unpredictable and non-repeatable. For the same seed, you will not get the same data.

With this set-up, you could start with a sudorandom seed and prime the quantum chip with it. Wait a reasonable length of time and recover the now changed and truly randomised data.

There are other quantum properties we can use to further enhance our randomness. One such property that creates headaches for classic for modern computing is quantum tunnelling. We are pretty much at the point of the nm scale that if we go much smaller, electrons may just elect to jump to another bit of the chip.

We can use that too. The chip that reads the randomised qbits could itself have a fine enough size that electrons will at times put themselves somewhere unintended. Use that for the data in and the data out, and we now have an array of bits that had three episodes of randomisation. This step is not necessary, but it would speed up the time to true randomness for each set of 64 bits.

The technology exists for true randomness

None of what I have suggested is beyond our current technology level. Other than the very small nm chip design, which might need a little R&D to perfect. We can make this if we want to.

I see a few possible uses for this idea:

1. Cryptography for robust and secure internet connections and the like
2. Gaming, especially for procedurally generated and rough-like games
3. Computer-generated graphics where a certain kind of noise is needed

How to steal this idea

If you are someone with the means to take this idea and turn it into a product, I ask only for accreditation and some company shares as a thank you.

Over to you

I’d love to hear your thoughts and comments. Agree, disagree, or point out a flaw in my thinking – it’s all good. Talk to me.

The banners are for my Pixel Wall project.

Password Game is the original (web-only) evil password validator game. More polished versions came later, but this is the OG original sin against security.

The scoring system works with cookies. You can disable cookies and still enjoy the games, but you don’t get a score. Nothing is saved or recorded.

I’d like to propose an extension of the OpenGraph protocol for easy wishlist creation. A select few might be aware that I maintain a wishlist. Currently, I manually enter each gift idea into a database. It would be dead helpful, if I could just provide a link to a page that represents an item that can be given.

This post contains some marked-up HTML and I don’t know how it will look on federated sites. You may need to open the original page for best results.

Existing art that might work

OpenGraph pretty much has what I need already.

<meta property="og:type" content="product.book" />

As far as I can tell, the list of types in the product space is as follows – album, book, drink, food, game, movie, product, song, and tv_show. Some of this maps well to gift listing.

• album is generally a thing you can buy and, thus, gift (digital purchases and releases are a bit fuzzy)
• book is a thing you can buy (includes ebooks or all kinds)
• drink is probably a thing you can buy or, sometimes, make
• food can be a thing you buy as a gift but is not strictly limited to that
• game is largely a thing that one can gift but exceptions apply
• movie is a thing you can watch but might map to DVD or Blueray which can be gifted
• product (product.product) is generic and is probably giftable
• song is something you listen to but might map to CD or digital for a given single
• tv_show is something you watch but could map to Box Set (DVD/Blueray/etc.)

However, there are some giftable things that do not fit well within the defined product types.

• A custom voucher for a favour like babysitting, housework, a shoulder massage, and other no-spend gifts.
• Something that you could make such as a cake, cookies, pie, a custom set of shelves, a GWL card, and so much more.
• The clarity that the product in question is something that can conceptually be given. Perhaps in a given format or media.

I considered adding one more product value

To the product types, I would like to add something that indicates the thing that can be given. The simplest version of that is probably “gift” or “giftidea”. It would set the page as a thing that a person can gift to another. Which would make it ideal for wishlists. Something like this:

<meta property="og:type" content="product.gift" />

This is not entirely a good fit. “Product” as a gift is conceptually a little narrow and is a bit too abstract for my tastes. Plus, it could break existing validators that are unaware of the new gift product type.

The other option would be a new base type with its own subtypes. This is problematic as it would create the possibility for duplicate potential types for a given page. Fortunately, there is a better way.

A namespace for OpenGraph gift ideas and wishlists

That better way uses good old namespaces.

If the type is not the right place to insert metadata for giftables, perhaps a new schema might be called for to cover instances when the current OpenGraph types are not a good fit. This gives us, I think, three new objects – gift idea, the wishlist, and an entry in a wishlist. Maybe it would look something like this:

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:gift" />

This type would provide a catchall for wishlist gift ideas that don’t fit well into the wider graph. It would also avoid breaking validators. The same namespace could be used for all wishlist, gift, and wish object data.

wishlist:gift object data

The namespace could provide other wishlist item data points – estimated price(s), and known retailers, for example.

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:wishlist:gift:price" content="£32.99" />
<meta property="og:wishlist:gift:price" content="$99.99" />
<meta property="og:wishlist:gift:retailer" content="amazon.co.uk" />
<meta property="og:wishlist:gift:retailer" content="CEX" />
<meta property="og:wishlist:gift:retailer" content="Harry's Local Trade Shop" />

There is a lot more data that could be added here but I’m not sure it is strictly necessary. Maybe there is something that should be here but I’ve not thought of. I think that the rest of the data – product information, could be covered by the existing OpenGraph namespace. If there are any obvious gaps, please comment, reply, or mention with your thoughts.

wishlist:list object data

If we’re going to have a custom namespace, why not also include the wishlist itself? This can be where each wish in the list could go (technical limits may apply).

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:list" />
<meta property="og:wishlist:list" content="https://example.com/lists/matt/birthday/" />
<meta property="og:wishlist:list:user" content="Matt" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/tfdobl" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/apple" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/cake" />
<meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-2" />
<meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-3" />

For wishlist:list:user, I toyed with calling this “wisher” and a few other things but finally concluded that there was no good reason to invent new terms when the existing idea of a site user or member was already well established.

There are other data points that might fit inside the graph for a wishlist. Please suggest any you think I should add here.

wishlist:wish object data

Wishlist entry implies the existence of wish with details such as – the gift wished for, how badly you want it (priority), how many you want, why you want it, and the list the wish is from. The whole thing might look like this:

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:wish" />
<meta property="og:wishlist:wish:gift" content="https://example.com/shop/item/tfdobl" />
<meta property="og:wishlist:wish:priority" content="low|medium|high" />
<meta property="og:wishlist:wish:quanitity" content="1" />
<meta property="og:wishlist:wish:why" content="This book is the only one missing from my collection." />
<meta property="og:wishlist:wish:inlist" content="https://example.com/lists/matt/wishlist-birthday" />

There are maybe other optional elements. Please do suggest data points you think should go here. Is, for example, wishlist:wish:why the best way to label that information within the graph?

Existing OpenGraph object data

OpenGraph neatly provides most of the other data points that could matter, I think.

<meta property="og:title" content="Fictional Dictionary of Bad Language" />
<meta property="og:url" content="https://example.com/giftideas/tfdobl" />
<meta property="og:image" content="https://example.com/images/tfdobl.jpg" />
<meta property="og:description" content="..." />
<meta property="og:determiner" content="the" />
<!-- ect. -->

One small privacy issue

While writing this, it occurred to me that I did not really want to put my postal address and other sensitive information online as part of a social graph. To avoid that I went ahead and assumed that the wishlist site handling the list for the user would implement some way for gift-givers to privately obtain such data if it was even needed at all. Perhaps with some sort of request/grant system or some other similar privacy controls.

Thoughts and feedback?

That’s my ideas about presenting wishlists, gifts, and wishlist items using OpenGraph. I’m open to critique, objections, praise, or any other feedback.

Today, I learned that gov.uk websites use Mark Down – a system for marking up text that can safely be turned into HTML. So too does the Universal Credit Journal system (sort of).

It looks like the journal system is trying to use Mark Down, and the specific code for that is fighting it hard.

I have discovered that it tries to throw rounded brackets (like this) around links. By default, “GOV.UK Notify will convert the URL into a link for you.” This is what is happening with the URLs added into the Universal Credit Journal, but the output method refuses to process the Mark Down. The UK government even has its own beucracy laided URL shortening system to make Mark Down links easy to read.

‘I have no way of knowing if it was decided that the general public was not to be trusted with the very safe Mark Dow system; or if it was determined that Universal Credit claments were too stupid to use it; or if the hack job that is the Journal system is just that badly written.