Technically you are defining state machines and state transition rules. These states typically represent integrations between backend systems (internal and external) and sometimes human processes such as physically delivering products by mail.

I talk about Step Functions here, but that is just the Amazon product. Azure has Durable Functions and most other cloud platforms probably have something similar. The interesting thing to me is the new low-code programming paradigm that they are enabling.

The Big Promise

When you define your business processes with Step Functions, you gain a few important abilities:

• Visualization: It’s easy to render the business process as a visual graph. In fact, AWS Console does this automatically for all Step Function executions.
• Observability: You can see the current state of your business process and what’s going to happen next. You can also track errors in once central place.
• Retrying: When an error occurs in an operation in the middle of the business process, you can have rules to automatically retry the operation before giving up.
• Error handling: When an error occurs in the middle of your business process, the entire process is aborted. The error is not mysteriously lost in a swamp of log files. You don’t end up in a “nothing happens” state because a Lambda function didn’t trigger the next SQS or SNS message.
• Scalability: If your business process involves operations that can run in parallel, Step Functions will let you do that and collect the results. The process will continue when all the parallel steps have completed.
• Modularity: When your business process is defined as a collection of independent states whose input and output are JSON objects, it becomes possible to exchange the implementation of any state with something else that consumes and emits the same JSON objects.

All these abilities are features that you could program yourself from scratch, but now you don’t have to. Instead, you define the broad outline of your business process using Amazon States Language (ASL). Then you add small pieces of actual code using TypeScript or Python or whatever language you wish to use.

The price is a learning curve. The ASL language itself is not complicated, but figuring out how to properly use it can sometimes be. The most challenging issue is how to model your state inputs and outputs. They are just regular JSON objects, but the way that Step Functions can process them is rather limited and the objects can get complicated.

The Challenge of Increasing Complexity

You will quickly experience the complexity of managing state inputs and outputs when you define a bigger Step Function that involves many states. Perhaps it has a Map state, a few Choice states, some Lambda function executions and some external Step Function executions. All these different operations return their outputs in different ways, and the state that is flowing through your state machine is affected by them.

For example, Lambda function output is received as a Payload object, which you typically assign to a Result object using ResultPath. If your Lambda function returns an object like {"hello": "world"}, the actual output will then be {"Result": {"Payload": {"hello": "world"}}.

If you happened to call that Lambda function from a Map state, you will actually get an array of those output objects. And since you again need to use ResultPath to preserve the original Step Function input, the output will look something like {"Result": [{"Result": {"Payload": {"hello": "world"}}, {"Result": {"Payload": {"hello": "world"}}]}.

To makes things a little more complicated, your states can also have Catch handlers which are called when an error occurs. They will receive the error object and they can return a valid output if they decide that the execution can continue. This introduces a new variation to your state machine, so sometimes the output might be {"Error": {"Error": "xxx", "Cause": "yyy"}}.

So, in my view, the main problem of Step Functions is how to mentally comprehend the exact structure of the input and output objects at any given state of the state machine. You very easily lose track of all those Results and Payloads and Errors. Then you typically start guessing and tweaking the inputs and outputs until the system appears to work. When your Step Function is complicated enough, you can’t manually test every possible state (including the error states), and you inevitably start introducing bugs to the logic.

How to Manage Complexity

The way that Step Functions pass an input object to the next state is basically like an undocumented API with no schema definition and no type checking. In my view, this is currently its biggest shortcoming. Lack of input/output schema definitions makes it difficult to develop complex state machines. It is entirely up to the developer to write down the schemas in comments or in some external documentation. That quickly gets verbose and inconvenient.

If Step Functions had built-in schemas for state input and output, you could validate the state transitions during development. For instance, when you use Visual Studio Code to develop your Step Functions, you might immediately see red errors when you’re trying to pass an invalid input to a state. This could also be a deploy-time feature of AWS CDK. It would refuse to deploy a state machine when it detected invalid state inputs. It would basically work like TypeScript type checking.

Another approach, perhaps complementary to schema validation, would be to visualize the inputs and outputs during development. Tooltip hints in Visual Studio Code would tell you what kind of input a state expects, what kind of output a state emits, and how they are transformed by the Step Functions directives like InputPath, OutputPath, ResultPath and ResultSelector.

A third solution, also complementary, would be to replace the current input / output directives with a more flexible JSON transformation feature. Currently, Step Functions can only “prune” JSON objects by picking one or more attributes from an output object. It would be much more helpful (although also much more complicated) to have transformation functionality similar to the jq CLI command. The jq command can process JSON objects and arrays dynamically and synthesize new objects from their attributes. That would let you “flatten” the outputs and to synthesize the inputs with more freedom, ultimately keeping the actual state as simple as possible.

The Next Level

I believe that Step Functions will not be programmed using code in the future. There will be visual tools for designing business processes and their state transitions. These tools will include schema validation features to manage the complexity issues I described earlier. They will make it foolproof to create Step Functions that will not fail because of an input/output syntax error. They will also warn you when they detect other logical errors in your process definition.

The new development tools will also let you embed TypeScript code (or other languages if you wish) into the state machine states where traditional programming is required. It will be possible to edit the entire business process visually, and drill down to the low-level code with a simple click. This will be either browser-based or happen inside Visual Studio Code.

I don’t believe in the idea of extending Step Functions with lower-level features that would replace manual programming completely. It’s not practical to write every single line of code with visual logic. Step Functions will define the broad strokes of your business processes and let you add more detailed logic using traditional code. The amount of traditional code will decrease but never quite reach zero.

I believe that the new visual tools will also cover other parts of your cloud infrastructure than just Step Functions. Ideally, you’ll use the same tools to design your REST APIs and GraphQL APIs and to define shared JSON data models and DynamoDB data tables. There will be some parts of your cloud stack that are not convenient to define using visual tools. You’ll define them using traditional AWS CDK code blocks or CloudFormation fragments when necessary.

With the increasing popularity of AWS CDK, more and more reusable abstract cloud components will be available. When someone has already designed a suitable Step Function or a Lambda function, or a more complicated AWS CDK Construct that solves your problem, you can just add it to your project. The new visual tools will need to be modular in this sense.

The overall goal will be to reduce unnecessary manual work (repetitively typing code) and also to reduce the cognitive load of remembering all the details of your business process in your head. Eventually you’ll be able to design and manage cloud-based systems using comfortable visual tools that let you easily zoom in to the low-level code when it’s necessary. This ultimately means less work and faster development times.

If you’d like to discuss this topic, you can just tweet to @kennu.

Since then, this blog has moved over to various technology platforms. They have been based on PHP, Python, Node.js and AWS Lambda. I’ve used at least Django, Drupal, WordPress and Contentful to manage the content. Contentful was the latest platform. It worked alright, but I never really enjoyed using it. To make it really comfortable, you need to build your own CMS user experience around Contentful.

Some time ago AWS released support for Lambda Layers. This made it possible to run PHP applications on Lambda. That, combined with faster VPC cold start times and EFS support, makes it possible to now run WordPress as a serverless application.

Here is the basic idea of my Serverless WordPress architecture:

As you can see, I’m not exposing WordPress directly to he Internet. Instead I’m exporting the content as static HTML and serving it through S3 and CloudFront. WordPress only works as a CMS management tool in this setup.

You might also notice that the architecture is not fully serverless. It still requires a MariaDB SQL server. AWS offers Aurora Serverless as a replacement, but I don’t appreciate its 30-second cold-start delay. It doesn’t work well with API Gateway’s maximum request timeout of 30 seconds. In practice you get an error whenever you try to use WordPress after being idle for long enough for Aurora to scale down to zero.

Everything else than MariaDB, however, scales down to zero quite cleanly. I won’t get charged unless I’m writing articles or someone actually reads the blog. CloudFront and S3 are billed by the number of HTTP requests and the amount of data transferred to the Internet. API gateway, Lambda and EFS are billed only when I’m actively writing articles. S3 and EFS are billed monthly for a tiny amount of data storage, but that’s counted in cents.

My experience so far is that WordPress works absolutely great as a Serverless application. Lambda adds a few hundred milliseconds to each request, but it’s not too much when you spend most of the time editing articles that are saved in the background. The user interface is great for quickly uploading images and experimenting with visual layouts.

In the long term I will need to update WordPress occasionally. It can’t update itself because the Lambda filesystem is read-only. This increases its security significantly as PHP files cannot be overwritten. I do have a deployment script that automatically downloads the latest WordPress package, configures WordPress, and deploys it as a Lambda function. The main risk, in my estimation, is that some WordPress bug allows malicious content to be injected into the SQL database before the bug is patched. Luckily that by itself does nothing until the malicious HTML is also exported to S3.

If you’d like to discuss this topic further, you can reach me on Twitter as @kennu.

The talk rejects casual use of big words like "architecture" and "technical debt" and demands you to define what they really mean when you use them.

Monica Lent's definition for software architecture is "enabling constraints". An architecture defines the constraints that will enable people to work productively on a project. When there is too little architecture, people will generate an overly complicated and hard to maintain system over time.

Cloud solution architects have been lucky in recent years. Amazon AWS provides a very well thought-out architecture for Serverless applications in particular. As an architect, you mainly need to know all the available building blocks and their non-functional attributes, such as pricing and scalability options. You can then create a cloud architecture just by combining these blocks into a system that matches your requirements.

Frontend architects need to do a bit more work, because they have more options available to them. There is some consensus about the most important things, like state management and component frameworks. You pick a state management framework like Redux or MobX, and a component framework like React, and together they define most of your architecture.

Architecture may also include a number of general development principles. Monica Lent's presentation includes some of them, such as inward-only pointing dependencies and conservative code reuse. There's nothing wrong with good principles, but developers will quickly forget them. If you want to enforce a principle, it needs to be somehow baked into the development process.

For example, AWS Lambda functions are always stateless, because they have no way to store state anywhere. This is often inconvenient at first, but the end result is an extremely robust and scalable microservice architecture. Lambda-based development enforces good architecture in this sense.

Amazon DynamoDB, on the other hand, presents a much more difficult architectural challenge. An architect may have initially designed a good database scheme for DynamoDB, but eventually developers need to add more entities and views to the system. DynamoDB doesn't set any constraints on what you store in the database and sooner or later bad decisions are made.

Referring to Monica Lent's talk again, one way to maintain best practices over time is to encode them into automated tests. Such tests can enforce specific rules about software dependencies, for example. The challenge, then, is how to write automated tests that enforce good DynamoDB database design. It's a challenging thought but certainly not impossible.

By moving the AWS credentials to 1Password, you will be able to delete your ~/.aws/credentials file, which is otherwise an attractive target for malware and other hacking attempts (but check the caveats section below before you do that).

Installation

First, install all the required software.

• Install the AWS CLI if you haven't already.
• Install the 1Password CLI tool.
• Install the jq tool, for instance using brew install jq on macOS.

Credential setup

Then, move your credentials from the local AWS credentials file to 1Password.

• Create a 1Password item to hold your AWS credentials. Use two custom fields to store the Access Key Id and Secret Access Key. In this example, the fields are named aws_access_key_id and aws_secret_access_key.
• Follow the 1Password instructions on how to perform the first sign-in using the op signin command, and how to sign in more easily after that (omitting the secret key).
• If you want to, remove the old credentials from ~/.aws/credentials.

Configuration

Next, add an entry that looks like this in your local ~/.aws/config file:

[profile my-account]
credential_process = sh -c "op get item 'Name Of Item' | jq '.details.sections[0].fields | map({(.t):.}) | add | {Version:1, AccessKeyId:.aws_access_key_id.v, SecretAccessKey:.aws_secret_access_key.v}'"

Make sure that Name Of Item matches the name you entered for the 1Password item, and that aws_access_key_id and aws_secret_access_key match the custom field names you used to store your Access Key Id and Secret Access Key. The above script assumes that they are in the first section. If you put them in a separate section, you may need to change the sections[0] clause to match it.

If you are on a platform that doesn't support the sh shell, you may neet to figure out how to perform a similar piping operation. Alternatively you could also create a separate script file somewhere, and move the complex script command line from ~/.aws/config to there.

Testing

Once the entry in ~/.aws/config is in place, you should be able to test the integration using AWS CLI:

aws --profile my-account iam get-user

If you see a valid-looking User JSON response that includes your AWS IAM UserId, UserName and Arn, congratulations, it's working properly. If you see an error, you may need to refresh your sign-in session first (op signin) and try again.

Caveats

When you remove your credentials from ~/.aws/credentials and use the credential_process option instead, some third party tools that use AWS SDK may stop working. For instance, I have created an issue about this in the Serverless Framework project. It's not quite clear whether Amazon plans to support this automatically in all AWS SDK based apps, or whether it's intended to be an AWS CLI only feature.

Cloudflare otti asiaan yllättävän jyrkän kannan ja alkoi blokata selainlouhintaa harjoittavia sivustoja. Mutta kun Flash-bannerimainokset aikanaan keksittiin, niihin olisi voinut suhtautua ihan samalla tavalla. Kukaan ei halunnut mainoksia ja ne kuluttivat kyselemättä sekä tietoverkkojen että tietokoneiden kapasiteettia.

Selainlouhintaa voi ajatella virtuaalimaksamisen yksinkertaistettuna muotona. Asiakkaan ei tarvitse erikseen hankkia valuuttaa lompakkoonsa ja suorittaa ostotransaktiota. Sen sijaan hän vain tarjoaa hieman oman tietokoneensa laskentakapasiteettia valuutan louhimiseen. Jos sivusto käyttää liikaa kapasiteettia, tietokone hidastuu häiritsevästi eikä käyttäjä viitsi enää palata sivustolle.

Toisin sanoen nyt on vihdoinkin keksitty keino, jolla käyttäjä saadaan maksamaan sisällöistä ja palveluista tekemättä varsinaista ostopäätöstä. Teknisesti ottaen hinta näkyy hieman kohonneena sähkölaskuna.

Insinööriluonteisia ihmisiä saattaa kismittää ajatus, että virtuaalivaluuttaa ja lohkoketjuja käytetäänkin pakotettuun louhintaan eikä mikromaksamiseen, kuten moni oli ajatellut. Selaimessa louhiminen on tehotonta ja haaskaa resursseja. Mutta konversioprosentti on lähellä sataa, sillä kukaan ei voi erikseen edes miettiä ostopäätöksen tekemistä.

Selainlouhintaa estämään on tietenkin jo kehitetty erilaisia laajennuksia, kuten esimerkiksi Coin-Hive Blocker. Jos louhinta on liian häiritsevää, estolaajennuksista saattaa tulla jopa virallinen osa selaimia. Tämä pätee erityisesti mobiiliselailuun, sillä akkukapasiteetin käyttäminen selainlouhintaan voi käydä nopeasti ärsyttäväksi.

Toisaalta voisi nähdä sellaisenkin tulevaisuuden, jossa palvelun ilmaisversio rahoitetaan selainlouhinnalla ja maksullisen version voi halutessaan tilata erikseen. Siinähän ei ole mitään erityisen uutta, että mainoksetkin saa pois maksamalla palveluista kuukausimaksua.

Jos käyttää vielä hitusen enemmän mielikuvitusta, niin selainlouhinnan voisi myös ulkoistaa kolmannelle osapuolelle. Silloin kännykän käyttäjä maksaisi siitä, että joku toinen taho suorittaa verkkopalvelun käytön edellyttämän selainlouhinnan hänen puolestaan, jolloin kännykän akku ei tyhjenisi.

Kauemmas tulevaisuuteen katsoessa herää kysymys, perustuvatko virtuaalivaluutat kuitenkaan ikuisesti louhintaa ja laskentakapasiteettia edellyttävään proof-of-work-malliin. Ethereumissa on jo suunniteltu siirtymistä proof-of-stake-malliin, joka jättäisi turhan laskennan kokonaan pois. Silloin selainlouhintakaan ei olisi enää mahdollista.

Toisaalta verkkopalveluissa liikkuu niin paljon rahaa, että kyllä jokin virtuaalivaluutta niitä jää tarvittaessa pyörittämään proof-of-work-mallillakin. Eikä sekään ole mahdoton ajatus, että selainlouhintaa varten keksitään jossain vaiheessa ihan uudenlainen, juuri siihen tarkoitukseen optimoitu lohkoketjutekniikka, joka ratkaisee esimerkiksi mobiilikäytön ongelmat uudella tavalla.

https://www.linkedin.com/pulse/could-cryptocurrency-kill-online-advertising-carl-whalley/

Nämä pakkopäivitykset jakaantuvat karkeasti ottaen kahtia: sellaisiin, joista kaikilla on yhteisymmärrys, ja sellaisiin, joista kiistellään. Viimeisin isompi kiista aiheutti Ethereumin jakaantumisen erilliseen Classic-haaraan. Samanlaisia haarautumisia on tapahtunut Bitcoinillekin.

Pakolliset päivitykset ovat sen vuoksi erityisen mielenkiintoisia, että ne muuttavat lohkoketjuun tallennettujen älysopimusten semantiikkaa. Tässä Byzantium-päivityksessäkin lisätään älysopimuksiin uusia toimintoja. Periaatteessa tietysti vanhat sopimukset pysyvät ennallaan, mutta varsinaisesti tästä ei ole mitään takeita, koska vanhojakin sopimuksia on toisinaan muutettu jälkeenpäin.

Pakkopäivitysten myötä ainakin allekirjoittaneelta on karissut puhtaan ideologinen usko lohkoketjujen ja älysopimusten pysyvyyteen jo jonkin aikaa sitten. Sopimuksista päätetään poliittisella konsensusprosessilla, jota hallinnoivat toisaalta Ethereumia kehittävä yritys ja toisaalta isot louhijatahot. Jos nämä yhdessä haluavat muuttaa sopimuksia jälkeenpäin, se onnistuu.

Ennen pitkää tullaan siis tilanteeseen, jossa älysopimuksista syntyviä erimielisyyksiä täytyy tulkita myös "oikean maailman" oikeuslaitoksessa. Siitä tulee mielenkiintoista, koska lohkoketju on globaali mutta lait ja tuomioistuimet eivät. Miten toimitaan tilanteessa, jossa vaikkapa yhdysvaltalainen yritys on myynyt suomalaisille omistajille virtuaalisia osakkeita, ja osakkeet yllättäen katoavatkin lohkoketjusta pakkopäivityksen myötä?

https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/

Facebook on puolestaan kehittänyt TypeScriptille kilpailijan nimeltä Flow. Se toimii samalla periaatteella, eli osaa varoittaa tyyppivirheistä ja kääntää koodin niinikään tavalliseksi JavaScriptiksi. Se toimii niin Atomissa kuin Visual Studio Codessa, kuten TypeScriptkin.

Pointti näissä molemmissa tyyppijärjestelmissä on se, että tyyppejä tarvitsee määritellä vain sen verran kuin itse parhaaksi katsoo. Kehittämisen voi aloittaa tuttuun tapaan dynaamisesti ilman erillisiä tyyppimerkintöjä. Sitten, kun jokin kohta koodissa alkaa näyttää turhan monimutkaiselta ja vaikeasti hahmotettavalta, siihen voi lisätä tyypityksen.

Yksinkertaisissa web-projekteissa tyypityksestä on oikeastaan eniten iloa silloin, kun käytettävät kirjastot sisältävät valmiit tyyppimääreet. Esimerkiksi AWS SDK -kirjastoa käyttäessä näkee jo editorissa varoituksen, mikäli on unohtanut jonkin parametrin DynamoDB-hausta. Tämä nostaa tuottavuutta aika merkittävästikin silloin, kun virheen muuten huomaisi vasta paljon myöhemmin Lambda-funktiota pilvessä ajaessa.

Oleellista on, että tyyppien käyttöönotto ei tee JavaScript-kehityksestä yhtä jäykkää kuin kokonaan staattisiin tyyppeihin perustuvissa kielissä, kuten Javassa tai vaikkapa Haskellissa. Olin itse aiemmin huolissani tyypityksen "viraalisuudesta", joka pakottaisi lisäämään tyyppimääreet ketjureaktiomaisesti kaikkialle, mutta toistaiseksi on vaikuttanut siltä, että muutaman any-tyypin lisääminen tarvittaessa sinne tänne riittää ainakin TypeScriptissä ja luultavasti Flowssakin. Tämä riippunee kuitenkin paljolti myös käytettyjen kirjastojen tyypityksen tasosta.

Netistä löytyy erilaisia vertailuja TypeScriptin ja Flown eroista enkä osaa vielä itse lähteä ottamaan niihin juurikaan kantaa. Jollain tavalla pitäisi kuitenkin osata päättää, haluaako sitoa oman koodinsa mieluummin Microsoftin vai Facebookin teknologiaan. Toistaiseksi TypeScriptin käyttökokemus on ollut erittäin hyvä, mutta toisaalta koska käytän myös paljon Reactia, Flow houkuttaa tavallaan enemmän.

Eräs TypeScriptin selkeimmistä eduista omassa käytössäni on ollut serverless-plugin-typescript, joka tekee TypeScriptin käyttämisestä Serverless-mikropalveluissa erittäin helppoa. Se kääntää .ts-tiedostot automaattisesti .js-tiedostoiksi ja julkaisee Lambda-funktiot pilveen. TypeScript sisältää myös async/await-tuen, joten mitään lisäkikkailua Babelilla ei tarvita.

Pahoin pelkään, että saman lopputuloksen saaminen aikaan Flowlla vaatisi paljon enemmän erilaisten pluginien asentamista ja konfigurointia, ja se async/await-tukikin pitäisi luultavasti virittää jonnekin erikseen. Luultavasti käytän sen vuoksi itse ainakin tässä vaiheessa enemmän TypeScriptiä, mutta seuraan samalla Flow-työkalujen kehittymistä.

Jossain vaiheessa edessä voi vielä olla vanhojen TypeScript-annotaatioiden vaihtaminen Flow-annotaatioksi. Sitten nähdään kuinka paha rasti sekin on. Toisaalta mikropalveluiden ja Amazon Lambdan ansiosta tällaiset migraatiot ovat nykyään aika pieniä ja ne voi tehdä aina vain yhteen mikropalveluun kerrallaan – ainakin jos on osannut pitää palvelut oikeasti mikrokokoisina.

Julkaisuprosessi on nyt: Contentful ⇒ Markdown ⇒ Phenomic ⇒ Amazon S3 ⇒ CloudFront

Contentful on vaihdellut ajan mittaan ilmaisen käytön rajoituksiaan, joten nähtäväksi jää, sopiiko se jatkossakin henkilökohtaiseen käyttöön. Tällä hetkellä ilmaiseksi voi luoda kolme erillistä sivustoa, joissa kussakin voi olla 10.000 artikkelia. Contentfullin sisältömalli on toimiva ja yksinkertainen, ja sopii hyvin yhteen markdown-sisällön kanssa, joten tarvittaessa ei ole suuri ongelma siirtää sisältöjä sieltä jonnekin muualle.

Esiin nousi lähinnä kaksi kilpailevaa vaihtoehtoa:

(1) Sivuttaminen käyttäen HTTP-metadata-otsakkeita kuten X-Total-Count, X-Page-Count, jne. Tällöin varsinainen JSON-tieto voidaan palauttaa taulukkomuotoisena (array).

(2) Taulukon kuorruttaminen metadata-objektilla. Rajapinnan palauttama tieto on silloin esimerkiksi muodossa {"items":[…], "totalCount":123}.

Kummallakin vaihtoehdolla on hyviä ja huonoja puolia, jotka ovat pitkälti periaatteellisia. Itse olen nykyään enemmän käytännöllisyyden kuin periaatteellisuuden kannalla, joten kallistun tässä tapauksessa vaihtoehtoon (1).

Perusteluni tälle ovat:

• Rajapinnan peruskäyttötapaus on mahdollisimman yksinkertainen, koska se palauttaa aina arrayn. Vastaanottajan ei tarvitse tehdä minkäänlaista sovitusta poimiakseen kuorruteobjektista erillisen "items"-attribuutin.

• Sama periaate sopii sekä sivutettuihin että sivuttamattomiin rajapintoihin. Jos rajapinta ei tue sivuttamista, se ei palauta X-otsikoita. Kummassakin tapauksessa palautettu data on aina JSON-array. Vastaanottaja voi jättää sivuttamisen kokonaan huomiotta mikäli ei tarvitse sitä.

• Rajapinnan kehittämisen voi huolehti aloittaa ilman sivutusta. Jos sivutusta myöhemmin kuitenkin huomataan tarvittavan, se voidaan laajentaa siististi aiemman rajapinnan päälle X-otsakkeilla, aiheuttamatta välittömiä yhteensopivuusongelmia.

• X-otsakkeiden käyttö toimii nykyään selaimissa ongelmitta CORSin kanssa, kunhan rajapinta palauttaa asianmukaisen Access-Control-Expose-Headers-otsakkeen.

• X-otsakkeet on nykyään helppo lukea selainten fetch()-rajapinnan palauttamasta vastineesta metodilla response.headers.getHeader('X-Total-Count').

Linkit keskusteluihin:
https://twitter.com/kennu/status/890271051657220096 https://www.facebook.com/kennu/posts/10155607701699468

https://twitter.com/kennu/status/890271051657220096

Gitin osalta asia on tietysti erilainen riippuen siitä, puhutaanko avoimen lähdekoodin projekteista vai yksityisistä projekteista. Avoimien projektien on suotavaa olla salaamattomasti näkyvissä koko maailmalle, mutta toisaalta niissäkin on usein tarpeita säilytellä yksittäisiä salattuja tiedostoja, joihin pääsevät käsiksi vain harvat ja valitut.

Yksityiset projektit voisivat olla kokonaan salattuja, jolloin kehitystiimien pitäisi jakaa keskenään salausavaimet päästäkseen koodiin käsiksi. Tämä on toisaalta ristiriidassa nykyaikaisten web-työkalujen kanssa, sillä GitHubin ja Bitbucketin kaltaiset palvelut olettavat pääsevänsä käsiksi versiohallintaan tallennettuun dataan muodostaakseen siitä diffejä ja pull-requesteja.

Ongelma olisi kenties ratkaistavissa käyttämällä repositoryissa useaa eri salausavainta, joista yksi annettaisiin GitHubille web-käyttöliittymää varten. Jollain toisella avaimella taas salattaisiin sellaiset tiedostot, joita edes GitHubin ei haluta näkevän. Kaikki data olisi kuitenkin repositoryissa salattuna, sekä pilvessä että kehittäjien koneilla, ja täten yhtenäisesti hallittavissa salausavaimia käyttäen.

En tiedä taipuuko Git tähän ja onko sen kehittäjillä halukkuuttakaan viedä sitä tähän suuntaan. Alan kuitenkin nyt ounastella, että tässä asiassa tapahtuu vielä suuri murros, joka voi johtaa uudenlaisten versiohallintojen käyttöönottoon.

https://twitter.com/kennu/status/882589814901673986