Une API de cartes statiques qui ne nécessite pas de clé.
Une API de cartes statiques qui ne nécessite pas de clé.
Static vs Dynamic Website — What’s the Difference in 2019?
Static vs Dynamic Website — What’s the Difference in 2019?TIME-SENSITIVE. Please publish on Tuesday, 5th FebruaryStatic (JAMstack) sites vs Dynamic — what’s the difference in 2019?Lately, there has been a lot of talk across the dev community related to traditional web development and how things are shifting in a certain direction. Static websites are back, big time! Thanks to modern web architecture like #jamstack, static websites are becoming a better solution for web developers.For quite a while, I’ve been trying to spread the word about JAMstack, simply because I have been relying on its architecture and the JAMstack in general, due to its many advantages. Gradually focusing on JAMstack improved my workflow and dev process but more importantly, it helped me to leave the problems of standard (...)
Digital Agency Shares the Benefits of Building a Static Website
Static sites are a big hit today. There are many advantages to having your website static, mainly performance and security. But will static sites stand the test of time? What is the real experience of developing and maintaining a static site? And how does it stand compared to dynamic websites built with traditional CMSs like Wordpress? I had a privilege to talk with Adam Judd, Managing Director of DiscoverIT, which is a UK based digital agency with a core focus on digital, about how they redesigned their own site using JAMstack methodology. That includes Vue.js framework, Nuxt.js static site generator and a headless CMS Kentico Cloud.Ondrej: Adam, I know you had an existing website that you decided to redesign. Can you explain your motivation?Adam: Our original site was built on a (...)
QuickStart an API-powered Static Website
Cosmic JS is a decoupled, or headless, content management system that empowers teams to build apps faster, together. Cosmic JS provides a suite of APIs to help you build your project and manage content, regardless of your app’s programming language.In this tutorial I’ll introduce a static website that can give you the best of both worlds: A website that is both dynamically powered by the Cosmic JS API and also a static website that can be edited using Markdown files. As a bonus, you can also setup automatic builds using Webhooks. I’m going to use the Cosmic JS CLI to install this Static Website, and I encourage you to read the original article to see how it’s built. You can install, deploy and edit every part of this Static Website from your Cosmic JS Bucket Dashboard. ?TL;DR:API-powered (...)
A New Publishing Tool | Getty Publications
We are developing Quire, a new publishing tool—optimized for publication discoverability and longevity—that uses a static-site generator, Hugo, to create and output titles in multiple formats from plain text files. E-book files are distribution-ready for Amazon, Apple, and other vendors; PDF files are print-on-demand ready. And the online edition can be hosted on any web server, with no special configurations or installations necessary and no backend databases or content management system to update and support over the long term.
In traditional website publishing, a content management system (CMS) is connected to collections and image databases (1) and set up on a server (2). The CMS is used to create the website, and once the website is published, the CMS rebuilds the site pages each time they are loaded by a user (3). Thus, the CMS must be kept running for the lifetime of the publication.
In static-site publishing, the CMS is just software and a folder of files on your, the publisher’s, computer (1) that are used to build the site. The site files are then uploaded to the server (2), and users (3) access them directly. You only need to run the site software and upload new files if you want to make updates to the publication.
Book production with CSS Paged Media at Fire and Lion
I love the many small, technical puzzles that designing books with CSS presents. There are also some much bigger challenges that we’re tackling, and where community effort might go a long way.
First, multiformat thinking is hard. The whole point of our digital-first approach is to store content only once, and produce multiple formats automatically. This puts tremendous pressure on project managers, developers, authors, editors, designers and proofreaders to think in multiple formats at once.
For instance, on the web, hyperlinks are cheap: you can add them anywhere, attach them to any text, and the design can keep them out of the reader’s way. In print, hyperlinks vanish or, if presented as page numbers, take up space and attention. Another example I mentioned above is interactivity: the text in the filmstrip figures in The Economy has to be sensitive to the fact that readers might be looking at clickable slides or at a static, printed page. And when controlling the flow of text, editors have to be aware of things like what happens when an element is floated: it appears beside the text it precedes in HTML, which can be counterintuitive for things like sidenotes beside paragraphs.
Like many publishers, we’ve had to invest a lot in training our team in multi-format thinking.
Second, manual page refinement is time-consuming. Automated layout with CSS gets us far, taking care of perhaps 90 per cent of a traditional typesetter’s role. But after that a human still has to check every page and refine many of them. On The Economy, I spent three or four hours on each chapter making small tweaks to get figures and sidenotes to fall in just the right place for maximum readability. On most novels, we spend at least three or four hours manually adjusting letter-spacing and soft hyphenation to avoid bad breaks, widows, orphans, and short lines.
If there is one thing we need better automation for, it’s proper, typographically sensitive widow-and-orphan control.
Third, technical skills are expensive. Extraordinary demand for developers worldwide means that dedicated technical team members are completely unaffordable for most publishers. If you’re going to create books with HTML and CSS, you need technical skills on the team, either in-house or in partnership with an outsourced team you can really trust.
In our team, we dedicate a significant piece of everyone’s time to technical skills development – both editors and designers – to reduce dependency on developers. And, as our technical lead, I have to spend at least half my time learning or training others. A commitment to digital-first publishing is a commitment to a serious learning curve.
The understated innovation of static site generators
This article is a reflection on the bigger picture around the new generation of static sites generators that are currently gaining traction and adoption.Static site generators have been around for a while and an early player in the field was Jekyll, which gained a lot of traction at launch, triggered the birth of GitHub Pages and hence created a developer-friendly solution to content. We’re now seeing a new wave of static site generators like GatsbyJS, that no longer are limited to publishing needs of the developer audience (as in, manage your content completely on GitHub), and instead have the ambition of becoming the new tool for content publishing.The current wave of static site generators comes with an entire ecosystem that makes the movement wider in scope than site-building tools (...)
Guide into Static Site Generators
The Evolution of Computer Science: from the Static to the Dynamic Paradigm
the developer philosopher© ▻http://feaforall.com/wp-content/uploads/2013/04/1.jpgYou can read a lot of things about the evolution of computer science although it is a relatively young recognized science. The most controversial topics tend to be about general paradigms of thinking: object-oriented vs functional programming, declarative vs imperative programming, RISC vs CISC, SQL vs NoSQL, etc. Of the classic debates, most are settled or irrelevant. However, in this brief article I would like to show that the main trend in computer science is a transition from static to dynamic things.WTF are you talking about ?In general, dynamic means capable of change, while static means stationary or fixed. Here are a couple of examples, applied to computer science, showing that a lot of things have (...)
The maps project aims to build cartography technologies for all #Wikimedia projects, at a scale sufficient for their widespread usage.
The production maps cluster (See also on Wikitech) is in development by the WMF Discovery team. The implementation has various components including:
– #Kartotherian Github (primary) / Gerrit (mirror) - a server capable of providing #map #tiles in #vector (pbf) or raster (png) formats, as well as #static_map snapshots of any size for a given location.
– Tilerator Github (primary) / Gerrit (mirror) – a distributed backend tile generation service with a jobque
– A flexible sources system to set up the needed storage and processing pipeline
A version of the tile server is now in operation at maps.wikimedia.org.
– It serves tiles at URLs such as
– It can scale images for the high-DPI devices – e.g. 1.5x, 2x, etc …/firstname.lastname@example.org
– It can provide static maps with a given size and scaling, e.g.
Kartotherian - OpenStreetMap Wiki
Kartotherian is a vector tile server based on open-source Mapbox stack, developed by Wikimedia Foundation for use on Wikipedia. It is horizontally scalable and designed for high loads.
Kartotherian is a set of 3 services:
– Kartotherian - tile server itself.
– Tilerator - tile rendering queue.
– Tilerator-UI (optional) - UI for issuing commands to Tilerator.
While Kartotherian can be configured to generate tiles on the fly straight from PostgreSQL, this is intended for development use only and the main mode of operation is to convert vector tiles generated by Tilerator into whatever user-requested format. An HTTP cache such as Varnish is recommended for reducing load on Kartotherian.
I looked at existing #static_site generators like Jekyll, Middle and Nanoc. All had complicated dependencies to install and took far longer to render my blog
Je m’intéresse aux générateurs de sites statiques de l’écosystème de #node.js :
Mes critères sont : simplicité, rapidité de prise en main, extensibilité, pas de langage de templates tout pourri (genre jade ou mustache).
Après quelques essais, j’ai une petite préférence pour wintersmith (+ #nunjucks pour les templates).
Quelques articles à propos de sa prise en main / configuration :
autre très intéressant article sur le blog de davidtucker, sur l’automatisation de son workflow avec #grunt.js
Simple, blog-aware, static sites
Its input is simply a directory of Markdown text files, and a basic transformation script automatically renders the blog HTML from them as needed.
You can browse or download the source code on GitHub here.
Transform your plain text into static websites and blogs.
No more databases, comment moderation, or pesky updates to install—just your content.
Markdown (or Textile), Liquid, HTML & CSS go in. Static sites come out ready for deployment.
Permalinks, categories, pages, posts, and custom layouts are all first-class citizens here.
Hyde is a static website generator written in python. While Hyde took life as awesome Jekyll’s evil twin, it has since been completely consumed by the dark side and has an identity of its own.
Pour mériter la mention de « blog » un site doit permettre l’interaction - si possible le trackback et au moins le commentaire. Un site statique est fort pratique, mais ce n’est pas un blog... A moins d’abandonner les commentaires à un service tiers et perdre ainsi son indépendance.
Mof, un blog c’est avant tout une suite d’articles réguliers, présentés du plus récent au plus vieux (= log, journal). Et c’est tout. Le fait qu’il y ait des commentaires ou pas n’a aucune incidence, un blog c’est pas forcément fait pour discuter, mais avant tout pour publier du contenu, dans un ordre daté.
Justement, je suis persuadé que l’essence même de la publication est la participation à une discussion - fut-elle sous-entendue... Même un blog purement statique, sans fonctionnalité de commentaires, participe à une discussion. Je déplore donc que le trackback ne soit pas plus pratiqué - le maillage des articles les enrichit mutuellement. De même, j’espère qu’un protocole tel que Salmon (►http://www.salmon-protocol.org) parviendra à redonner une unité aux discussions éclatées dans les réseaux décentralisés.
32 Static Website Generators For Your Site, Blog Or Wiki
Sometimes, all a geek needs is a quick way to generate a static site and put it up on a server or hosting service like Amazon S3 or GitHub Pages. We’ve compiled a list of static website generators that can be used for exactly this purpose:
#Blatter #Blogofile #Bonsai #Chisel #Dynamicmatic #Frank #Hobix #Hyde #ikiwiki #Jekyll #Jinja #Korma #Lanyon #Mako #Markdoc #Middleman #nanoc #Pagegen #Stacey #Tahchee #Templeet #Toto #ttree #Pelican #Poole #Pubtal #Sphinx #StaticMatic #Static #Vee #Webby #Webgen
Hu ça existe encore Templeet, excellent ! J’avais testé ça ya longtemps quand j’étais à l’IUT, ça avait l’air excellent, et j’avais l’intention de l’utiliser comme noyau pour me faire un CMS... Et puis ensuite je suis tombé dans SPIP et je n’ai plus vraiment eu le temps d’approfondir.
Pelican is a static site generator, written in Python.
Write your content directly (...) in reStructuredText, Markdown, or AsciiDoc formats
Includes a simple CLI tool to (re)generate your site
Easy to interface with distributed version control systems and web hooks
et, comment rajouter un type de fichier :
via @karlpro et @ametaireau
divers services (commerciaux) qu’on peut brancher sur un site
(il y a une certaine contradiction dans tout ça)
Open Content & Design Comes to #jQuery
The link between #WordPress and the #static content repositories is a grunt build and deployment process that processes the content files and synchronizes them into a WordPress installation using XML-RPC. That means we don’t ever use the WordPress Administration pages; all authoring and editing just happens in your favorite text editor, then grunt does the hard work.
Cool, mais est-ce qu’il existe le même type d’API abstraite comme leaflet, mais pour du statique ? Parce que là c’est pour UN fournisseur de fond (comme Google donc). Mais on pourrait imaginer utiliser quasiment la même API que pour les cartes JS (cad les mêmes noms de paramètres etc) mais pour récupérer juste une image. Avec à peu près les mêmes fonctionnalités : affichage de points, de contours KML ou autre.
@rastapopoulos à ma connaissance non ce la n’existe pas. J’ai repéré quelques plugins qui pourraient peut être répondre à ton besoin :
Il faut tout de même bien différencier Google de Mapbox . Avec l’API de Mapbox tu peux utiliser n’importe quel fond de carte si tu utilises des données ouvertes, alors que chez Google tu ne disposes que des couches qu’ils proposent.
Réponse rapide du support de Mapbox à propos des restrictions d’usage de leur API statique :
“A free MapBox account allows you up to 3,000 views/month. This includes both tiled views and static image views. We recommend signing up for an account to avoid being blocked if you go over 3,000.”
« The main idea of project is to create a web application which will provide a service of embedding map images. So each webmaster/developer will be able to easily put any map on his webpage. The map is going to be embedded in HTML code just like an usual image. Maps can be presented as an image in different formats (jpeg, gif etc). Also the type of map will be configurable, so by changing url parameter webmaster will be able to choose if he wants to display a cycle map or a skiing map. »
Dépôt du projet d’API statique pour les cartes osm (qui date un peu). C’est celui qu’on utilise sur lestaxinomes.org pour l’instant, mais à ce que m’en disent les gens sur irc osm il n’y a pas vraiment d’api officielle pour ça. On m’a plutôt recommandé de me tourner vers l’api de mapquest. Il faut vraiment être motivé dès qu’il s’agit de jouer avec osm/openlayers...