Profile

Cover photo
John Valentine
83 followers|37,274 views
AboutPostsCollectionsPhotosYouTube+1's

Stream

John Valentine

Shared publicly  - 
 
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.
1
Add a comment...

John Valentine

Shared publicly  - 
 
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)
1
Add a comment...

John Valentine

Shared publicly  - 
 
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.
1
1
Add a comment...

John Valentine

Shared publicly  - 
 
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.
1
Add a comment...

John Valentine

Shared publicly  - 
 
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
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.
1
Add a comment...

John Valentine

Shared publicly  - 
 
Developer Decisions: TDD, Redux, ES6

We're applying Redux and TDD to this project.

TDD (test-driven development)

Adopting TDD means we're starting again from scratch, because we have a lot of 'formally untested' code. Our code was manually tested, but that approach could have invisibly introduced bugs into the app.

The #TDD method requires us to add a tiny part of the specification to the app, then write only the minimum code that allows the app to pass that specification test. Then we write another test, implement it, repeating the cycle. This is a very effective way of keeping the bug count close to zero, and achieve tight cycles, so that our app grows quickly and reliably. If something breaks, then our last change introduced the problem, and it's relatively easy to fix.

We use mocha and chai for automated tests, which are triggered every time we save a file in our source code.

Redux

We're adopting #Redux in response to our earlier reported difficulties, where it was tricky to have interface trigger a change in the app data, and ensure the re-rendering of state.

At 16.02.003, we were most of the way towards creating code that would centrally handle any requests to change the data, along with a predefined list of possible actions, a central data store to prevent fragmentation of data concerns, and a way of re-building new states. This might seem very clever, but it was unnecessary: Redux has already solved this problem for us, and is the end-point of where our 'engineering' would have taken us :o) Open Source to the rescue!

Redux lets us define actions, call the action from our UI, and write reducers that implement the actions by compiling a new state, based on the old state and the action requested. These are 'pure functions' (they don't create side-effects, and rely only on the parameters passed to them, rather than their own internal stored state, or an external state). Pure functions are predictable, which makes them easily testable, supporting our TDD methodology.

We also need to treat the 'previous state' as immutable, which means we cannot change it in the reducer. Instead, we build a new copy of the state, modified to the needs of the action. ES6 gives us some syntactic sugar to make this a lot easier, and produce readable code.

Screenshot

Here's an example of the reducer code, and the three tests that led to its creation. The code uses some of the ES6 shorthand that honours 'immutability of state', and helps keep our code readable. In case you're wondering, the other 3 tests (of 6) tested the initial app state.
1
John Valentine's profile photoToby Bettridge's profile photo
2 comments
 
I learnt and used TDD in my last job and I'm trying to get my new place to use it too. It may well not be a cure-all but I've yet to see any downside other than its not as much fun as diving in and coding straight away. The fun comes later when you can deploy code to live without being anywhere near as stressed.

I'm happy to know that there is a large section of www.tate.org.uk that can be deployed in minutes because a broken test would halt the release script.

(I'd have commented on this on Facebook but it wouldn't let me - we have a mutual friend in Bob)
Add a comment...
Have him in circles
83 people
Abid Iqbal's profile photo
Language Codes's profile photo
Philip Storry's profile photo
Tristan Greaves's profile photo
Michelle Thomson's profile photo
Kath McCarron Humphrey's profile photo
Neil Treeby's profile photo
Domenico Lizio's profile photo
Susan Beard's profile photo

Communities

John Valentine

Shared publicly  - 
 
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

2
Add a comment...

John Valentine

Shared publicly  - 
 
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
5
Add a comment...

John Valentine

Shared publicly  - 
 
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
1
1
Add a comment...

John Valentine

Shared publicly  - 
 
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.
1
Add a comment...

John Valentine

Shared publicly  - 
 
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
You’ll find your components much easier to reuse and reason about if you divide them into two categories.
1
Add a comment...

John Valentine

Shared publicly  - 
 
Developer Decisions: App structure and tooling

After a break, we're back to reviewing the existing code-base. It looks like we'll be favouring #Redux, as a clean method for data and program flow.

Given that this project is, at best, opportunistic with the time dedicated to it, it's likely that we won't be posting about new features for a little while, as we implement the new app structure.

After that work, we foresee that the app will grow faster than it did before.
1
Add a comment...
John's Collections
People
Have him in circles
83 people
Abid Iqbal's profile photo
Language Codes's profile photo
Philip Storry's profile photo
Tristan Greaves's profile photo
Michelle Thomson's profile photo
Kath McCarron Humphrey's profile photo
Neil Treeby's profile photo
Domenico Lizio's profile photo
Susan Beard's profile photo
Communities
Basic Information
Gender
Male
Links
Other profiles
Links
John Valentine's +1's are the things they like, agree with, or want to recommend.
Hawking radiation is not produced at the black hole horizon.
backreaction.blogspot.com

Stephen Hawking’s “Brief History of Time” was one of the first popular science books I read, and I hated it. I hated it because I didn’t und

Sphere in Mirrored Spheroid | Visual Insight
blogs.ams.org

A spheroid is an ellipsoid with an axis of rotational symmetry. This image created by Refurio Anachro shows a sphere inside a mirrored spher

YouTube - Zenith gameplay demo 2 (moderate game)
www.youtube.com

Create AccountSign In. Home. BrowseFilmsUpload. Hey there, this is not a commercial interruption. You're using an outdated browser, whic

The Sentinel is an Extraordinary Computer Game (1986) - STUCK ON AMBER
stuck-on-amber.typepad.com

Rarely a digital game reached that level of formal beauty. Brilliant use of design constraints, tense atmosphere, and 10,000 levels to explo