I Use This!
Very High Activity

News

Analyzed about 6 hours ago. based on code collected 1 day ago.
Posted over 4 years ago
Imagine that you’ve been going from shop to shop looking for a cow-shaped butter dish. Later, you walk into a department store and a salesperson walks right up to you … Read more The post Browse in peace on your phone with Firefox thanks to Enhanced Tracking Protection appeared first on The Firefox Frontier.
Posted over 4 years ago
Imagine that you’ve been going from shop to shop looking for a cow-shaped butter dish. Later, you walk into a department store and a salesperson walks right up to you … Read more The post Browse in peace on your phone with Firefox thanks to Enhanced Tracking Protection appeared first on The Firefox Frontier.
Posted over 4 years ago by Fernando Serrano
Today we are introducing ECSY (Pronounced “eck-see”): a new -highly experimental- Entity Component System framework for Javascript. After working on many interactive graphics projects for the web in the last few years we were trying to identify the ... [More] common issues when developing something bigger than a simple example. Based on our findings we discussed what an ideal framework would need: Component-based: Help to structure and reuse code across multiple projects. Predictable: Avoids random events or callbacks interrupting the main flow, which would make it hard to debug or trace what is going on in the application. Good performance: Most web graphics applications are CPU bound, so we should focus on performance much more. Simple API: The core API should be simple, making the framework easier to understand, optimize and contribute to; but also allow building more complex layers on top of it if needed. Graphics engine agnostic: It should not be tied to any specific graphics engine or framework. These requirements are high-level features that are not usually provided by graphics engines like three.js or babylon.js. On the other hand, A-Frame provides a nice component-based architecture, which is really handy when developing bigger projects, but it lacks the rest of the previously mentioned features. For example: Performance: Dealing with the DOM implies overhead. Although we have been building A-Frame applications with good performance, this could be done by breaking the API contract, for example by accessing the values of the components directly instead of using setAttribute/getAttribute. This can lead to some unwanted side effects, such as incompatibility between components and a lack of reactive behavior. Predictable: Dealing with asynchrony because of the DOM life cycle or the events’ callbacks when modifying attributes makes the code really hard to debug and to trace. Graphics engine agnostic: Currently A-Frame and its components are so strongly tied to Three.js that it makes no sense to change it to any other engine. After analyzing these points, gathering our experience with three.js and A-Frame, and looking at the state of the art on game engines like Unity, we decided to work on building this new framework using a pure Entity Component System architecture. The difference between a pure ECS like Unity DOTS, entt, or Entitas, and a more object oriented approach, such as Unity’s MonoBehaviour or A-Frame's Components, is that in the latter the components and systems both have logic and data, while with a pure ECS approach components just have data (without logic) and the logic resides in the systems. Focusing on building a simple core for this new framework helps iterate faster when developing new applications and lets us implement new features on top of it as needed. It also allows us to use it with existing libraries as three.js, Babylon.js, Phaser, PixiJS, interacting directly with the DOM, Canvas or WebGL APIs, or prototype around new APIs as WebGPU, WebAssembly or WebWorkers. Technology stack examples Architecture We decided to use a data-oriented architecture as we noticed that having data and logic separated helps us better think about the structure of our applications. This also allows us to work internally on optimizations, for example how to store and access this data or how to get the advantage of parallelism for the logic. The terms you must know in order to work with our framework are mostly the same as any other ECS: Entities: Empty objects with unique IDs that can have multiple components attached to it. Components: Different facets of an entity. ex: geometry, physics, hit points. Components only store data. Systems: Where the logic is. They do the actual work by processing entities and modifying their components. They are data processors, basically. Queries: Used by systems to determine which entities they are interested in, based on the components the entities own. World: A container for entities, components, systems, and queries. ECSY Architecture Example So far all the information has been quite abstract, so let’s dig into a simple example to see how the API feels. The example will consist of boxes and circles moving around the screen, nothing fancy but enough to understand how the API works. We will start by defining components that will be attached to the entities in our application: Position: The position of the entity on the screen. Velocity: The speed and direction in which the entity moves. Shape: The type of shape the entity has: circle or box. Now we will define the systems that will hold the logic in our application: MovableSystem: It will look for entities that have speed and position and it will update their position component. RendererSystem: It will paint the shapes at their current position. Circles and balls example design Below is the code for the example described, some parts have been omitted to abbreviate (Check the full source code on Github or Glitch) We start by defining the components we will be using: // Velocity component class Velocity { constructor() { this.x = this.y = 0; } } // Position component class Position { constructor() { this.x = this.y = 0; } } // Shape component class Shape { constructor() { this.primitive = 'box'; } } // Renderable component class Renderable extends TagComponent {} Now we implement the two systems our example will use: // MovableSystem class MovableSystem extends System { // This method will get called on every frame by default execute(delta, time) { // Iterate through all the entities on the query this.queries.moving.results.forEach(entity => { var velocity = entity.getComponent(Velocity); var position = entity.getMutableComponent(Position); position.x += velocity.x * delta; position.y += velocity.y * delta; if (position.x > canvasWidth + SHAPE_HALF_SIZE) position.x = - SHAPE_HALF_SIZE; if (position.x < - SHAPE_HALF_SIZE) position.x = canvasWidth + SHAPE_HALF_SIZE; if (position.y > canvasHeight + SHAPE_HALF_SIZE) position.y = - SHAPE_HALF_SIZE; if (position.y < - SHAPE_HALF_SIZE) position.y = canvasHeight + SHAPE_HALF_SIZE; }); } } // Define a query of entities that have "Velocity" and "Position" components MovableSystem.queries = { moving: { components: [Velocity, Position] } } // RendererSystem class RendererSystem extends System { // This method will get called on every frame by default execute(delta, time) { ctx.globalAlpha = 1; ctx.fillStyle = "#ffffff"; ctx.fillRect(0, 0, canvasWidth, canvasHeight); // Iterate through all the entities on the query this.queries.renderables.results.forEach(entity => { var shape = entity.getComponent(Shape); var position = entity.getComponent(Position); if (shape.primitive === 'box') { this.drawBox(position); } else { this.drawCircle(position); } }); } // drawCircle and drawCircle hidden for simplification } // Define a query of entities that have "Renderable" and "Shape" components RendererSystem.queries = { renderables: { components: [Renderable, Shape] } } We create a world and register the systems that it will use: var world = new World(); world .registerSystem(MovableSystem) .registerSystem(RendererSystem); We create some entities with random position, speed, and shape. for (let i = 0; i < NUM_ELEMENTS; i++) { world .createEntity() .addComponent(Velocity, getRandomVelocity()) .addComponent(Shape, getRandomShape()) .addComponent(Position, getRandomPosition()) .addComponent(Renderable) } Finally, we just have to update it on each frame: function run() { // Compute delta and elapsed time var time = performance.now(); var delta = time - lastTime; // Run all the systems world.execute(delta, time); lastTime = time; requestAnimationFrame(run); } var lastTime = performance.now(); run(); Features The main features that the framework currently has are: Engine/framework agnostic: You can use ECSY directly with whichever 2D or 3D engine you are already used to. We have provided some simple examples for Babylon.js, three.js, and 2D canvas. To make things even easier, we plan to release a set of bindings and helper components for the most commonly used engines, starting with three.js. Focused on providing a simple, yet efficient API: We want to make sure to keep the API surface as small as possible, so that the core remains simple and is easy to maintain and optimize. More advanced features can be layered on top, rather than being baked into the core. Designed to avoid garbage collection as much as possible: It will try to use pools for entities and components whenever possible, so objects won’t be allocated when adding new entities or components to the world. Systems, entities, and components are scoped in a “world” instance: It means that we don’t register the components or systems on the global scope, allowing you to have multiple worlds or apps running on the same page without interferences between them. Multiple queries per system: You can define as many queries per system as you want. Reactive support: Systems can react to changes in the entities and components Systems can get mutable or immutable references to components on an entity. Predictable: Systems will always run in the order they were registered or based on a priority attribute. Reactive events won’t generate “random” callbacks when emitted. Instead they will be queued and processed in order, when the listener systems are executed. Modern Javascript: ES6, classes, modules What’s next? This project is still in its early days so you can expect a lot of changes with the API and many new features to arrive in the upcoming weeks. Some of the ideas we would like to work on are: Syntactic sugar: As the API is still evolving we have not focused on adding a lot of syntactic sugar, so currently there are places where the code is very verbose. Developer tools: In the coming weeks we plan to release a developer tools extension to visualize the status of the ECS on your application and help you debug and understand its status. ecsy-three: As discussed previously ecsy is engine-agnostic, but we will be working on providing bindings for commonly used engines starting with three.js. Declarative layer: Based on our experience working with A-Frame, we understand the value of having a declarative layer so we would like to experiment with that on ECSY too. More examples: Keep using a diverse range of underlying APIs, such as canvas, WebGL and engines like three.js, babylon.js , etc. Performance: We have not really dug into optimizations on the core and we plan to look into it in the upcoming weeks and we will be publishing some benchmarking and results. The main goal of this initial release was to have an API we like so we could then focus on the core in order to make it run as fast as possible. You may notice that ECSY is not focused on data-locality or memory layout as much as many native ECS engines. This has not been a priority in ECSY because in Javascript we have far less control over the way things are laid out in memory and how our code gets executed on the CPU. We get far bigger wins by focusing on preventing unnecessary garbage collection and optimizing for JIT. This story will change quite a bit with WASM, so it is certainly something we want to explore for ECSY in the future. WASM: We want to try to implement parts of the core or some systems on WASM to take advantage of strict memory layout and parallelism by using WASM threads and SharedArrayBuffers. WebWorkers: We will be working on examples showing how you can move systems to a worker to run them in parallel. Please feel free to use Github to follow the development, request new features or file issues on bugs you find, our discourse forum to discuss how to use ecsy on your projects, and ecsy.io for more examples and documentation. [Less]
Posted over 4 years ago by Fernando Serrano
Today we are introducing ECSY (Pronounced “eck-see”): a new -highly experimental- Entity Component System framework for Javascript. After working on many interactive graphics projects for the web in the last few years we were trying to identify the ... [More] common issues when developing something bigger than a simple example. Based on our findings we discussed what an ideal framework would need: Component-based: Help to structure and reuse code across multiple projects. Predictable: Avoids random events or callbacks interrupting the main flow, which would make it hard to debug or trace what is going on in the application. Good performance: Most web graphics applications are CPU bound, so we should focus on performance much more. Simple API: The core API should be simple, making the framework easier to understand, optimize and contribute to; but also allow building more complex layers on top of it if needed. Graphics engine agnostic: It should not be tied to any specific graphics engine or framework. These requirements are high-level features that are not usually provided by graphics engines like three.js or babylon.js. On the other hand, A-Frame provides a nice component-based architecture, which is really handy when developing bigger projects, but it lacks the rest of the previously mentioned features. For example: Performance: Dealing with the DOM implies overhead. Although we have been building A-Frame applications with good performance, this could be done by breaking the API contract, for example by accessing the values of the components directly instead of using setAttribute/getAttribute. This can lead to some unwanted side effects, such as incompatibility between components and a lack of reactive behavior. Predictable: Dealing with asynchrony because of the DOM life cycle or the events’ callbacks when modifying attributes makes the code really hard to debug and to trace. Graphics engine agnostic: Currently A-Frame and its components are so strongly tied to Three.js that it makes no sense to change it to any other engine. After analyzing these points, gathering our experience with three.js and A-Frame, and looking at the state of the art on game engines like Unity, we decided to work on building this new framework using a pure Entity Component System architecture. The difference between a pure ECS like Unity DOTS, entt, or Entitas, and a more object oriented approach, such as Unity’s MonoBehaviour or A-Frame's Components, is that in the latter the components and systems both have logic and data, while with a pure ECS approach components just have data (without logic) and the logic resides in the systems. Focusing on building a simple core for this new framework helps iterate faster when developing new applications and lets us implement new features on top of it as needed. It also allows us to use it with existing libraries as three.js, Babylon.js, Phaser, PixiJS, interacting directly with the DOM, Canvas or WebGL APIs, or prototype around new APIs as WebGPU, WebAssembly or WebWorkers. Technology stack examples Architecture We decided to use a data-oriented architecture as we noticed that having data and logic separated helps us better think about the structure of our applications. This also allows us to work internally on optimizations, for example how to store and access this data or how to get the advantage of parallelism for the logic. The terms you must know in order to work with our framework are mostly the same as any other ECS: Entities: Empty objects with unique IDs that can have multiple components attached to it. Components: Different facets of an entity. ex: geometry, physics, hit points. Components only store data. Systems: Where the logic is. They do the actual work by processing entities and modifying their components. They are data processors, basically. Queries: Used by systems to determine which entities they are interested in, based on the components the entities own. World: A container for entities, components, systems, and queries. ECSY Architecture Example So far all the information has been quite abstract, so let’s dig into a simple example to see how the API feels. The example will consist of boxes and circles moving around the screen, nothing fancy but enough to understand how the API works. We will start by defining components that will be attached to the entities in our application: Position: The position of the entity on the screen. Velocity: The speed and direction in which the entity moves. Shape: The type of shape the entity has: circle or box. Now we will define the systems that will hold the logic in our application: MovableSystem: It will look for entities that have speed and position and it will update their position component. RendererSystem: It will paint the shapes at their current position. Circles and balls example design Below is the code for the example described, some parts have been omitted to abbreviate (Check the full source code on Github or Glitch) We start by defining the components we will be using: // Velocity component class Velocity { constructor() { this.x = this.y = 0; } } // Position component class Position { constructor() { this.x = this.y = 0; } } // Shape component class Shape { constructor() { this.primitive = 'box'; } } // Renderable component class Renderable extends TagComponent {} Now we implement the two systems our example will use: // MovableSystem class MovableSystem extends System { // This method will get called on every frame by default execute(delta, time) { // Iterate through all the entities on the query this.queries.moving.results.forEach(entity => { var velocity = entity.getComponent(Velocity); var position = entity.getMutableComponent(Position); position.x += velocity.x * delta; position.y += velocity.y * delta; if (position.x > canvasWidth + SHAPE_HALF_SIZE) position.x = - SHAPE_HALF_SIZE; if (position.x < - SHAPE_HALF_SIZE) position.x = canvasWidth + SHAPE_HALF_SIZE; if (position.y > canvasHeight + SHAPE_HALF_SIZE) position.y = - SHAPE_HALF_SIZE; if (position.y < - SHAPE_HALF_SIZE) position.y = canvasHeight + SHAPE_HALF_SIZE; }); } } // Define a query of entities that have "Velocity" and "Position" components MovableSystem.queries = { moving: { components: [Velocity, Position] } } // RendererSystem class RendererSystem extends System { // This method will get called on every frame by default execute(delta, time) { ctx.globalAlpha = 1; ctx.fillStyle = "#ffffff"; ctx.fillRect(0, 0, canvasWidth, canvasHeight); // Iterate through all the entities on the query this.queries.renderables.results.forEach(entity => { var shape = entity.getComponent(Shape); var position = entity.getComponent(Position); if (shape.primitive === 'box') { this.drawBox(position); } else { this.drawCircle(position); } }); } // drawCircle and drawCircle hidden for simplification } // Define a query of entities that have "Renderable" and "Shape" components RendererSystem.queries = { renderables: { components: [Renderable, Shape] } } We create a world and register the systems that it will use: var world = new World(); world .registerSystem(MovableSystem) .registerSystem(RendererSystem); We create some entities with random position, speed, and shape. for (let i = 0; i < NUM_ELEMENTS; i++) { world .createEntity() .addComponent(Velocity, getRandomVelocity()) .addComponent(Shape, getRandomShape()) .addComponent(Position, getRandomPosition()) .addComponent(Renderable) } Finally, we just have to update it on each frame: function run() { // Compute delta and elapsed time var time = performance.now(); var delta = time - lastTime; // Run all the systems world.execute(delta, time); lastTime = time; requestAnimationFrame(run); } var lastTime = performance.now(); run(); Features The main features that the framework currently has are: Engine/framework agnostic: You can use ECSY directly with whichever 2D or 3D engine you are already used to. We have provided some simple examples for Babylon.js, three.js, and 2D canvas. To make things even easier, we plan to release a set of bindings and helper components for the most commonly used engines, starting with three.js. Focused on providing a simple, yet efficient API: We want to make sure to keep the API surface as small as possible, so that the core remains simple and is easy to maintain and optimize. More advanced features can be layered on top, rather than being baked into the core. Designed to avoid garbage collection as much as possible: It will try to use pools for entities and components whenever possible, so objects won’t be allocated when adding new entities or components to the world. Systems, entities, and components are scoped in a “world” instance: It means that we don’t register the components or systems on the global scope, allowing you to have multiple worlds or apps running on the same page without interferences between them. Multiple queries per system: You can define as many queries per system as you want. Reactive support: Systems can react to changes in the entities and components Systems can get mutable or immutable references to components on an entity. Predictable: Systems will always run in the order they were registered or based on a priority attribute. Reactive events won’t generate “random” callbacks when emitted. Instead they will be queued and processed in order, when the listener systems are executed. Modern Javascript: ES6, classes, modules What’s next? This project is still in its early days so you can expect a lot of changes with the API and many new features to arrive in the upcoming weeks. Some of the ideas we would like to work on are: Syntactic sugar: As the API is still evolving we have not focused on adding a lot of syntactic sugar, so currently there are places where the code is very verbose. Developer tools: In the coming weeks we plan to release a developer tools extension to visualize the status of the ECS on your application and help you debug and understand its status. ecsy-three: As discussed previously ecsy is engine-agnostic, but we will be working on providing bindings for commonly used engines starting with three.js. Declarative layer: Based on our experience working with A-Frame, we understand the value of having a declarative layer so we would like to experiment with that on ECSY too. More examples: Keep using a diverse range of underlying APIs, such as canvas, WebGL and engines like three.js, babylon.js , etc. Performance: We have not really dug into optimizations on the core and we plan to look into it in the upcoming weeks and we will be publishing some benchmarking and results. The main goal of this initial release was to have an API we like so we could then focus on the core in order to make it run as fast as possible. You may notice that ECSY is not focused on data-locality or memory layout as much as many native ECS engines. This has not been a priority in ECSY because in Javascript we have far less control over the way things are laid out in memory and how our code gets executed on the CPU. We get far bigger wins by focusing on preventing unnecessary garbage collection and optimizing for JIT. This story will change quite a bit with WASM, so it is certainly something we want to explore for ECSY in the future. WASM: We want to try to implement parts of the core or some systems on WASM to take advantage of strict memory layout and parallelism by using WASM threads and SharedArrayBuffers. WebWorkers: We will be working on examples showing how you can move systems to a worker to run them in parallel. Please feel free to use Github to follow the development, request new features or file issues on bugs you find, our discourse forum to discuss how to use ecsy on your projects, and ecsy.io for more examples and documentation. [Less]
Posted over 4 years ago by Niko Matsakis
Today we're happy to announce that we're starting a second blog, the Inside Rust blog. This blog will be used to post regular updates by the various Rust teams and working groups. If you're interested in following along with the "nitty gritty" of Rust development, then you should take a look!
Posted over 4 years ago by Miriam Suzanne
CSS is the design language of the web — one of three core web languages — but it also seems to be the most contentious and often perplexing. It’s too easy and too hard, too fragile and too resilient. Love it or hate it, CSS is weird: not quite ... [More] markup, not quite programming in the common (imperative) sense, and nothing like the design programs we use for print. How did we get here? I’ve seen some people claim that “CSS is for documents” — as though HTML and JavaScript weren’t also originally for documents. The entire web was for documents, but that hasn’t stopped us from pushing the medium to new extremes. This is a young platform, and all the core languages are growing fast, with CSS advancing leaps and bounds over the last few years. But there is a real problem: the web is fundamentally device-agnostic, and therefor display-agnostic. The original website from CERN states the problem clearly: This implies no device-specific markup, or anything which requires control over fonts or colors. Here we are, putting fonts and colors on the web. But it’s worth taking a step back and asking: what does it even mean to design for an unknown and infinite canvas? This problem isn’t new, it’s not going away, and there are no simple answers – but if we’re going to talk about it, we have to understand the fundamental audacity of the task. Design on the web will always be weird – but CSS is a living document, and we have the power to keep making it better. The post Why is CSS so Weird? appeared first on Mozilla Hacks - the Web developer blog. [Less]
Posted over 4 years ago by Miriam Suzanne
CSS is the design language of the web — one of three core web languages — but it also seems to be the most contentious and often perplexing. It’s too easy and too hard, too fragile and too resilient. Love it or hate it, CSS is weird: not quite ... [More] markup, not quite programming in the common (imperative) sense, and nothing like the design programs we use for print. How did we get here? I’ve seen some people claim that “CSS is for documents” — as though HTML and JavaScript weren’t also originally for documents. The entire web was for documents, but that hasn’t stopped us from pushing the medium to new extremes. This is a young platform, and all the core languages are growing fast, with CSS advancing leaps and bounds over the last few years. But there is a real problem: the web is fundamentally device-agnostic, and therefor display-agnostic. The original website from CERN states the problem clearly: This implies no device-specific markup, or anything which requires control over fonts or colors. Here we are, putting fonts and colors on the web. But it’s worth taking a step back and asking: what does it even mean to design for an unknown and infinite canvas? This problem isn’t new, it’s not going away, and there are no simple answers – but if we’re going to talk about it, we have to understand the fundamental audacity of the task. Design on the web will always be weird – but CSS is a living document, and we have the power to keep making it better. The post Why is CSS So Weird? appeared first on Mozilla Hacks - the Web developer blog. [Less]
Posted over 4 years ago by Caitlin Neiman
Please meet our newest Friend of Add-ons, B.J. Herbison! B.J. is a longtime Mozillian and joined add-on content review team for addons.mozilla.org two years ago, where he helps quickly respond to spam submissions and ensures that public listings ... [More] abide by Mozilla’s Acceptable Use Policy. A software developer with a knack for finding bugs, B.J. is an avid user of ASan Nightly and is passionate about improving open source software. “The best experience is when I catch a bug in Nightly and it gets fixed before that code ships,” B.J. says. “It doesn’t happen every month, but it happens enough to feel good.” Following his retirement in 2017, B.J. spends his time working on software and web development programs, volunteering at a local food pantry, and traveling the world with his wife. He also enjoys collecting and studying coins, and playing Dungeons and Dragons. “I’ve played D&D with some of the other players for over forty years, and some other players are under half my age,” B.J. says. Thank you so much for your contributions to keeping our ecosystem safe and healthy, B.J.! If you are interested in getting involved with the add-ons community, please take a look at our current contribution opportunities. The post Friend of Add-ons: B.J. Herbison appeared first on Mozilla Add-ons Blog. [Less]
Posted over 4 years ago by Karl Dubost
We converted webcompat.com to Python 3, which included reconfiguring a couple of things on the server itself with nginx, uwsgi and so on. Let's say modernizing everything. As an aside, I would say that our unit tests made the code conversion to ... [More] python 3 quite smooth. That was a good surprise. In the process, I started to wonder if it would make it easier for us to switch to Docker and containers. These are my notes trying to educate myself about the topic. They are probably naive for some of the readers but might be useful for others. They will also become handy for this 2019Q4 OKR. 💡 Digital Ocean Digital Ocean has everything we need for using Docker with multiple tutorials and examples on both docker and digitalOcean websites. How To Install and Use Docker on Ubuntu 18.04 How To Build and Deploy a Flask Application Using Docker on Ubuntu 18.04 We are currently using: Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-42-generic x86_64) on staging and production. Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-98-virtual i686). we are not anymore. As we said, we modernized. 💡 Learning about Docker A very basic explanation easily understandable of what Docker is. Introduction about docker on Digital Ocean. The Dockerfile is a set of instructions/commands which will explain to the Docker container what it should install to be ready. It configures it basically. Docker images hold the snapshot of the Dockerfile, and the Docker container is a running implementation of a Docker image based on the instructions contained within that image. — Docker 101: Fundamentals & The Dockerfile We could imagine we would have, before/after(?) deploying: docker build -t staging/webcompat . docker build -t prod/webcompat . Translation: build (build) the image from the Dockerfile at the root level (.) and tag it -t as staging/webcompat. Docker compose helps to orchestrate all services in one unique place. is a recipe card — it’s a recipe of services that make up an application and the docker-compose.yml dictates how the services are mixed together. — Docker 102: Docker-Compose And it could be practical if everything is under docker. If you’re lucky enough to be able to use Docker containers in production, then a single docker-compose.yml file can deploy a complete system that runs exactly as it was tested in lower life cycle environments. — Docker 102: Docker-Compose A nice example on how this can be done. GitHub Actions We probably also need to explore GitHub Actions. There's an article about Digital Ocean Kubernetes and GitHub actions. Docker and Flask Some examples of docker + nginx + uwsgi + flask 💡 Docker Installation Get started with Docker Desktop for Mac. Debian buster 3.7.4 is the latest at the time of this writing for mimicking a production environment. ubuntu:20.04 > Debian Buster > ubuntu:18.04. We are currently running Ubuntu 18.04 💡 Docker for dev environment The reason number 1 is to speed up the setup process and then lower the bar to participation for coding. It’s a bit hard to start the webcompat project even with the docs. And there are a lot of things to configure just to fix one line of code. Time to time, for some people platforms differences created issues. Using Docker Containers As Development Machines Visual Studio Code can connect to a remote docker container instance. But they seem to refer to a couple of drawbacks with regards to time and dependencies in the project. An argument discouraging using docker for the development environment. When docker was introduced in our stack the first thing we noticed is that, while it simplified our initial setup and launch, it made our day to day development process much more complex. — Why using docker in your local dev environment is probably not a great idea Easy setup. Dev process harder. every command took almost twice as long to complete. — Why using docker in your local dev environment is probably not a great idea All the literature seems to be consistent with regards to using docker for the dev environment. Probably better to stick to a solid and simple virtual environment, and then have a script which makes it possible for people to deploy this code locally on their docker container that we would have prepared. So probably not something to recommend for now. 💡 Docker for deployment testing Probably Docker would be a very good thing to use for people deploying the project so they can test locally a couple of things before making the project live. The idea would be to reproduce the configuration of the DigitalOcean droplet. So we could checkout a branch version into a local docker container and see if the house is on fire. I could also see the possibility to have generic values for running functional and unit tests, which would be super stable across developers. To think. 💡 Docker for production This seems also to be a good choice with regards to what we want to do. It also kind of removes the stress of playing with the values in the live environment. Basically we can tweak the configuration in the container and then we think it’s ready deploy this specific instance. In this article, the author gives an example of deploying a container to DigitalOcean using docker-machine. $ docker-machine create --driver digitalocean --digitalocean-access-token xxxxx dash_app_droplet $ eval $(docker-machine env dash_app_droplet) Now, if you will run the $ docker-compose up --build -d it will deploy the app directly from the local host to the droplet. 💡 Docker and images/data We will need to handle the data at a different layer. Probably I should try to create an image which is mimicking our server configuration, to better understand how to fit the development and deployment workflows process in the big picture. Otsukare! [Less]
Posted over 4 years ago
Data breaches are one of many online threats. Using secure internet connections, updating your software, avoiding scam emails, and employing better password hygiene will all help you stay safer while … Read more The post Steps you can take to protect your identity online appeared first on The Firefox Frontier.