Profile cover photo
Profile photo
John Valentine
82 followers
82 followers
About
John's posts

We have closure

The CodedRaw object is now a closure. This lets us keep some properties and methods private, while exposing the items we choose.

The demo has been tidied up a bit, and describes itself better. Basic functionality remains the same.

Post has attachment
Inner Products ...or simple CSG

Here's a quick demo of a script I wrote in 2004. It creates a solid that, when viewed from different angles, shows a different letter. In this case, I have coloured lights so you can see the shadows from the object.

It should work reasonably well for any letter that has continuous content from left to right, and top to bottom. (I should also allow for typographical features to prevent loss of features that extend beyond guide lines)
Photo

Post has attachment
How do we know what math research is worthwhile? [tessellations]

Every so often, I take a peek at what's happening in mathematics or physics. I'm probably not alone when I think, "someone wrote a paper on that?". After a while, usually while cooking food for the family, I think a bit, around what I imagine to be the abstract and practical problems, and it's pleasantly interesting, but I wouldn't want to formally cover every nuance of the problem. A little while later, I might remember that I did something similar that was part of the wider category of associated problems, and wonder whether I could or should have explored it in more detail.

One of my feeds regularly reports on shape-packing: how to pack polygons into planes or surfaces, how to fit regular solids into each other, the polynomial solution that maximally crosses its own path, and so on.

This leads me on to an example: Minesweeper. It's not the P-NP problem that people think of; rather I was briefly interested in the way that differently-shaped minesweeper cells affected game balance. The case of a square is reasonably trivial: each square (not on the edge of the board) has 8 neighbours, and when you count the distribution of the squares that have 0, 1, 2, 3, … neighbouring mines, you can predict approximately how playable the game will be.

However, I didn't just write Minesweeper. I introduced variations: holes (inactive parts of the grid), linked cells (which tied two non-adjacent cells together for counting neighbouring mines), and shaped cells (which grouped contiguous cells into bigger areas).

Shaped cells proved most interesting, because using areas composed of squares, you could simulate other shapes of cell. For example, using 1×2 areas, you could create a pattern that matches a hexagonal game board by offsetting every second column of areas downwards one cell. A hexagonal board gives you a possible mine count in the range 0..6, so although the board construction seems less trivial, the gaming possibilities are more constrained.

We could also create shapes that have more neighbours, like the one pictured. Rather than the 8 neighbours of a square grid, this "Scroll Lock 2" variant has up to 9 neighbours. Other variants go further, or introduce patterns where there are easy and difficult cells. Large cells can make the smaller cells more difficult to solve, and so on.

Here's the question: is there potential for interesting mathematical exploration here? What would the intrinsic and derived properties be? Can this be applied usefully to anything else, or can other studies be applied here?

Refs:

[1] Here's the app, made for Windows 95–10 Desktop:
http://johnvalentine.co.uk/crossmines.php

Note that there's a bug, where, is you choose a 'pattern' game, you have to go in and choose the pattern each time.

[2] "How does one choose which bits of maths will be the ones to make the huge impact down the track?" https://plus.google.com/+DavidRoberts/posts/duMz4SU32ST

Photo

Post has attachment
Coded Raw - proof of concept

Our previous #CodedRaw post outlined the objective. Now, we've completed the first 'standard', which is a proof-of-concept demo in JavaScript.

I've not published it yet, because it's painfully minimal, uses no frameworks at all, and shows its results in the console.

When the GO button is pressed, the demo does this:
* Retrieve a CodedRaw file (AJAX), and treat it as a dynamic module;
* Discover the version of the file;
* Call the getContent() function within the file. This function receives the file's data, and returns a rendering;
* There's also a 'give me the raw data' function, which also works.

The CodedRaw file is 9 lines of JSON, and the CodedRaw reader script (which would be used by the client app) is about 20 lines of JavaScript, most of which is XMLHttpRequest boilerplate. The client calls it with "CodedRaw.getModule('S0-demo.json', CodedRaw.render)"

Other Standards

Below is a draft of the standards we've planned. They'll likely need a better workflow in the client, and some re-organisation of the CodedRaw code itself:

S1 is next, which returns image dimensions, and an array of RGB8 pixels by default.

S2 requires a CodedRaw file to declare its output formats and render any one of them on request. These formats will be defined in the standard. It also allows meta-data to be embedded, e.g. EXIF and CodedRaw data.

S3 implements optional parameters, which are values that a client app can expose, and then the parameters are fed to the getContent() function. An example of this might be an 'exposure' value for the image.
Photo

Post has attachment
This just in: https://www.theguardian.com/science/2016/may/28/eu-ministers-2020-target-free-access-scientific-papers

Is this far enough? Will it cross international boundaries now, and in the future? Are there any loopholes, and will the existing methods persist due to convoluted lock-in deals?

(Why is this good for science? See our previous post)
Tag: +David Roberts

Post has attachment
Coded Raw: a project for self-decoding media

I specified the Coded Raw project about ten years ago, which allowed a slim client application to decode a file, no matter how the file was encoded. The project is an ambitious attempt to pre-emptively solve important long-term problems centred around the reading of divergent and obsolete media.

It uses principles of dynamic object methods and functional programming to embed the methods within the file itself, effectively delegating the decoding responsibility from the workflow apps, to the file itself.

I'm thinking of reviving the project using JavaScript as the implementation target. The principles are well-sketched on the linked site: http://johnvalentine.co.uk/coded_raw

The diagram below shows an example scenario, of how workflows are preserved, when a camera with a new BIOS update saves the image in a new encoding. Spoiler: all existing Coded Raw apps would be able to read the new file format, even if the encoding is completely new.

There are problems to be solved, most notably:
(a) the creation of a secure sandbox for the execution environment;
(b) a way of embedding and retrieving the dynamic functions from the file;
(c) protocols for querying media for the best decoding methods;
(d) base standards, for basic methods, and parameter-driven decoding.

Next?

I'll develop a prototype app, just to demonstrate the principle, then throw it onto GitHub. I welcome any comments on this project, especially those that affect its viability (Devil's Advocates are as welcome as Enablers!).

I'm personally excited by this project, but need to be disciplined enough to keep it focused, so I'll be wearing my Agile hat.

#CodedRaw #JavaScript #camera-raw #photography #open-raw #functional-programming
Photo

Post has attachment
Quick iterative development

For client-side JS apps, of varying scales, I'm currently liking node, npm, webpack, as a development platform. npm/react-slingshot provides the basis, making good tooling decisions.

With hot reloading, eslint, and mocha+chai, I have very quick cycles of iterative development, mostly driven by TDD. After hitting "save" in my source file, the project is fully-tested within a fraction of a second.

I say "mostly driven by TDD", because it takes a lot of coding discipline to make everything pre-fail and then have a testable implementation. For example, UI elements and behaviours need to be mocked, or operated upon in a non-browser environment (like enzyme). I also relax my TDD discipline if I'm exploring new tools or patterns (i.e. breaking things creatively).

Example: Ticket Finder

I usually provide a screenshot with each post, so here's a mobile-first SPA (single-page-application) I made with react, redux, and the above-mentioned OS modules.

It queries a RESTful API service, via a hosted proxy to eliminate CORS problems (that is a nuanced decision, which I hope to write about soon, or provide links). The UI is snappy, filtering instantly. All the API access is asynchronous, using an isomorphic-fetch variant, redux-thunk and promises.

UI design

The interface is fairly conventional, adopting an always-present results stack that defaults to 'all results', so you start with something interesting to browse. It has a clean interface (left screenshot), with the filter hidden away until needed (middle screenshot).

Results are filtered live (like a Google search), with n results shown right alongside the "Search by Name" box, which gives mobile users an indication of how well their search term is working ("0 results" lets them revise it before scrolling down for disappointment!). The stack is paged, which reduces the downloading burden.

Further filtering is available via the drop-down lists, which get their options from the 'Search by Name' results, to avoid frustration. If any criterion is not provided, we assume not to filter by it.

User actions are guided. For example, the primary actions are green buttons, used sparingly: "More" and "Get Tickets". Blue buttons blend nicely with the theme, whose base colour can be tweaked with a single change to a line of SCSS (less). We didn't use Bootstrap here; the CSS was trivial enough.

The event tiles use the image assets that the API provides, and overlays gradients and text in a way that makes them readable, regardless of content.

Designed for failure

The client detects if the API is not available, along with three other fail conditions, which result in a friendly note in the app. With more time, a wish-list would include offline client-side storage of data, with appropriate warnings. We'd do this with 'interfaces' to abstract the service (example: http://chimera.labs.oreilly.com/books/1234000000262/ch04.html#interfaces).

Improving interfaces

This project-let led to some suggestions for improving the mobile experience with some API tweaks, and an image service.

And finally...

This little project, although it looks very simple, uncovers many developer decisions. Given that the client-side code is loaded via Webpack, I opted to use ES6/7 features, transpiled by Babel. This makes the redux 'immutable' coding much more concise and maintainable, due to its syntactic sugar for object deconstruction, and object spread. I also like the ES6 modules and variable scoping, which help with the separation of concerns.

This, along with TDD, inspires confidence in the process. I think it would survive the maintainability test, which is successful if one can return in a month or two, and still know how to maintain the project.
Photo

This is a new collection, here on G+. Now's your chance to opt in/out.

Here, I hope to expose some of the Open Source-based geekery that I enjoy. For each article, I might focus on a specific pattern, tool, or an app that I create.

I created this Collection, because I don't want to create distractions about 'how I did it' in my other collections (where I focus on the product, rather than the implementation details).

Secretly, I'm hoping this helps convince employers that I know what I'm talking about.

Post has attachment
Writing as a technical art

I think writing is an art in most respects. In saying that, I’m not saying it cannot be distilled into a science. Art and science are two outlooks on the same creative process: art attempts to mystify it, and science attempts to demystify it. I’m saying that the distinction depends on how well-defined the creative process is intended to be.

We can turn this distinction back on itself, to dissect how art works, to help demystify it, and then use our findings to help make our art better.

What is art?

When we think of art, we might assume paintings by respected artists. Everyone has different tastes in art. Here, I’m taking a wider view, to regard art as the presented product of any creative process, where we’re not necessarily interested in exposing how it was done. Art is supposed to be magic, where the artist has a talent that allows them to create works that present new or enjoyable experiences for others.

What is the magic?

More:
http://johnvalentine.co.uk/fiction.php?art=art_writing

Post has attachment
Containers and Components

To assist with re-usability, we'll be implementing our UI with the container-component pattern, which has a number of benefits.

Briefly, with container-component, you create re-usable components that are generic enough to be fed props to customize them. Any instance of the component then uses a container, to provide an interface to the relevant part of the data store.

This pattern also helps us to write separate reducers for each container, and sometimes may allow a reducer to operate on a limited data domain within the app state.

More: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.oqwneh6q3
Wait while more posts are being loaded