Donald Trump Tells Auto Makers They ‘Have to Start Making Things Here Again’
The president-elect called automotive trade between the U.S. and Germany a ‘one-way street’
President-elect Donald Trump told companies they will have to shift manufacturing to the U.S. in order to do business here, in a series of comments indicating a tough posture toward U.S. trade partners.
“Car companies and others, if they want to do business in our country, have to start making things here again.
Installing WordPress Locally on Your Mac With MAMP
What is MAMP?
MAMP stands for Macintosh, Apache, MySQL, and PHP. MAMP is an application you can install on your Mac which allows you to have access to a local PHP server and MySQL server. Essentially, MAMP gives you all of the tools you need to run WordPress on your machine, for development and testing purposes. You can accomplish this in different ways, but the other ways aren’t nearly as simple (see MacOS_X_Local_Mirror for the long, manual version of installing PHP and MySQL on your Mac).
Step 1: Installing MAMP
Before you can install MAMP on your Mac, you’ll need to download it from the MAMP website. MAMP requires that your Mac be running Mac OS X 10.6.6 or later.
Once the MAMP download is complete, double-click the MAMP disk image (it should be something like MAMP_2.0.3.dmg), and you should get a MAMP window pop up. Drag the MAMP folder (not MAMP PRO – we’ll save that walk-through for another time) to the Applications folder.
Step 2: Basic MAMP Settings
Now that you’ve got MAMP installed on your system, launch MAMP.app (located at /Applications/MAMP/MAMP.app).
While you’re editing settings, MAMP might prompt you for an administrator password. This is required because MAMP needs to run two processes: mysqld (MySQL) and httpd (Apache), and depending on the settings you set for those processes, you may or may not need to input your password.
Once you open MAMP, click the Preferences button. Next, click over to “Ports.” The default MAMP ports are 8888 for Apache, and 8889 for MySQL. If you use this configuration, you shouldn’t get asked for your password, but you’d need to include the port number in the URL (localhost:8888). If you’d like to leave the port number out of the URL, change the Apache port to 80. The downside of using port 80 as your MAMP Apache port is that you’ll always be asked for your password.
Lastly, on the Web Server tab, you’ll need to set a document root. This is where all of your files are going to be for your local web server. An example of a document root is /Users/USERNAME/Sites/wordpress/.
Once you’re done editing all of the settings, hit OK to save them.
Step 3: Starting MAMP Servers & Creating The Database
To start the MAMP Apache and MySQL servers, simply click “Start Servers” from the main MAMP screen. Your MAMP servers have now been started.
Once the MAMP servers start, the MAMP start page should open in your default web browser. If not, click on “Open start page” in the MAMP window. Once that’s open, select phpMyAdmin from the webpage.
Under “Create new database”, enter in a database name such as “wordpress”, and press “Create.” No need to choose an option for “collation” : it will automatically be assigned by MySQL when the database tables are created, during the WordPress installation.
Step 4: Downloading and Installing WordPress
Now it’s time to download WordPress. Once you’ve downloaded and unzipped the WordPress download, open up the “wordpress” folder. Click and drag all of the files from the wordpress folder to your MAMP document root (I use /Users/USERNAME/Sites/wordpress/).
Others with the default MAMP install should rename and drag the folder to the htdocs folder, located under /Applications/MAMP. Then in the browser, go to localhost:port/folder_renamed to run the install. For example, in the default MAMP install, if the folder was renamed wordpresstest, go to localhost:8888/wordpresstest.
Lastly, we’ve got to run WordPress’ famous 5-minute install. Visit your local site (localhost:port or localhost:port/wordpress), and enter the following information into the database setup form:
Database Name: wordpresstest
User Name (database): root
Password (database): root
Database Host/server: localhost
Table Prefix: wp_
Note that the default Database Name is “WordPress” and that you will need to change the Database Name to the name you entered into PHP Admin (in this case, “wordpresstest”). If you have multiple WordPress sites on your local machine, each of which is using its own database, you will need to make the Database Name in the WordPress configuration consistent with your second (or third or fourth) Database Name.
Once that’s complete, enter a blog name and email address, and you’re ready to use WordPress on your Mac.
Offline strategies come to the Service Worker Cookbook
By Salva Posted on October 19, 2016 in Featured Article and ServiceWorkers
serviceworke.rs is a compendium of common and uncommon Service Worker use cases including push examples, usage patterns, performance tips and caching strategies.
Service Worker Cookbook recipes are presented as playgrounds or labs, with fully functional client-server setups, where you can learn and experiment with results using in-browser developer tools.
Still, the cookbook is far from comprehensive, and we realised it lacked some basic materials and user feedback mechanisms. Today, I’m proud to announce some changes to the Service Worker Cookbook starting with a new section about caching strategies.
Caching Strategies
Caching strategies includes recipes that demo several ways of serving content from a service worker. The recipes follow an identical layout in which two iframes are displayed side by side. Both show an image element pointing to the same online picture.
The first iframe is not under service worker interception, so the picture always displays fresh content from the server. In contrast, the second iframe is controlled by the service worker and the content is served according to the implemented cache strategy.
Layout for offline recipes: two iframes, the first controlled and the second not.
Picture content changes on the server every 10 seconds and you have a button to refresh both iframes at the same time and compare what happens to the images.
cache-update-refresh-out-of-sync
Some of the caching strategies are taken from an inspiring article from Jake Archibald’s “The offline cookbook” and others are homegrown.
Cache only
The most basic example: With cache only, requests will never reach the network. Instead, they will be served by the service worker from a local cache.
self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(fromCache(evt.request));
});
function fromCache(request) {
return caches.open(CACHE).then(function (cache) {
return cache.match(request).then(function (matching) {
return matching || Promise.reject(‘no-match’);
});
});
}
In this implementation, cache-only assets are stored while installing the service worker and they will remain there until a new version of the worker is installed.
self.addEventListener(‘install’, function(evt) {
evt.waitUntil(precache());
});
function precache() {
return caches.open(CACHE).then(function (cache) {
return cache.addAll([
‘./controlled.html’,
‘./asset’
]);
});
}
You can use the cache-only strategy for your site’s UI related assets such as images, HTML, sprite sheets or CSS files.
Cache and update
This slight variation on the cache-only strategy also serves assets from a local cache but it also sends network requests for updated versions of the assets. The new content then replaces the older asset in the local cache.
self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(fromCache(evt.request));
evt.waitUntil(update(evt.request));
});
function update(request) {
return caches.open(CACHE).then(function (cache) {
return fetch(request).then(function (response) {
return cache.put(request, response);
});
});
}
With this cache and update strategy, there comes a point when your assets are no longer synched with those online, but they will be synched upon a second request, which roughly translates to a second visit.
It is totally fine to use this strategy when delivering independent, non-critical content such as avatars or icons. Avoid relying on this strategy for dependent assets (such a complete UI theme) since there is nothing ensuring that the assets will update as needed at the same time.
Cache, update and refresh
Another twist on the previous strategy, now with a refreshing ingredient.
With cache, update and refresh the client will be notified by the service worker once new content is available. This way your site can show content without waiting for the network responses, while providing the UI with the means to display up-to-date content in a controlled way.
self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(fromCache(evt.request));
evt.waitUntil(
update(evt.request)
.then(refresh)
);
});
function refresh(response) {
return self.clients.matchAll().then(function (clients) {
clients.forEach(function (client) {
var message = {
type: ‘refresh’,
url: response.url,
eTag: response.headers.get(‘ETag’)
};
client.postMessage(JSON.stringify(message));
});
});
}
This is especially useful when fetching any kind of content. This is different than the previous strategy in that there is no need for a user to refresh or visit the site a second time. Because the client is aware of new content, the UI could update in smart, non-intrusive ways.
Embedded fallback
There are situations in which you always want to always display something to replace content that’s missing for whatever reason (network error, 404, no connection). It’s possible to ensure always available offline content by embedding that content into the service worker.
self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(networkOrCache(evt.request).catch(function () {
return useFallback();
}));
});
// Dunno why this is shown as the actual SVG in WordPress but it looks awesome!
// You can see the source code in the recipe.
var FALLBACK =
” +
‘ ‘ +
‘ ‘ +
‘ ‘ +
‘ ‘ +
”;
function useFallback() {
return Promise.resolve(new Response(FALLBACK, { headers: {
‘Content-Type’: ‘image/svg+xml’
}}));
}
In this recipe, the SVG which acts as a replacement for missing content is included in the worker. As soon as it is installed, fallbacks will be available without performing new network requests.
Network or cache
Service Workers place themselves between the client and the Internet. To some extent, they allow the developer to model their ideal network behaviour. This strategy exploits/enhances that idea by imposing time limits on network responses.
self.addEventListener(‘fetch’, function(evt) {
evt.respondWith(fromNetwork(evt.request, 400).catch(function () {
return fromCache(evt.request);
}));
});
function fromNetwork(request, timeout) {
return new Promise(function (fulfill, reject) {
var timeoutId = setTimeout(reject, timeout);
fetch(request).then(function (response) {
clearTimeout(timeoutId);
fulfill(response);
}, reject);
});
}
With this recipe, requests are intercepted by the service worker and passed to the network. If the response takes too long, the process is interrupted and the content is served from a local cache instead.
Time limited network or cache can actually be combined with any other technique. The strategy simply gives the network a chance to answer quickly with fresh content.
User feedback
We want to know if recipes are useful, and if you find them clear or confusing. Do they provide unique value or are they redundant? We’ve added Disqus comments to recipes so you can share your feedback. Log in with Facebook, Twitter, Google or Disqus, and tell us how this recipe has served you or participate in the discussion about recommended use cases.
And more to come
We won’t stop here. More recipes are coming and new enhancements are on their way: a improved way to ask for recipes, an easier contribution pipeline, a visual refresh and a renewed recipe layout are things on our radar. If you like serviceworke.rs please share them with your friends and colleagues. Feel free to use these recipes in your talks or presentations, and, most importantly, help us by providing feedback in the form of on site comments, filing GitHub issues or by tweeting me directly 😉
Your opinion is really appreciated!
About Salva
Front-end developer at Mozilla. Open-web advocate, I love programming languages, cinema, music, video-games and beer.
More articles by Salva…
A Quantum Leap for the Web
Oct 27
Over the past year, our top priority for Firefox was the Electrolysis project to deliver a multi-process browsing experience to users. Running Firefox in multiple processes greatly improves security and performance. This is the largest change we’ve ever made to Firefox, and we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months.
But, that doesn’t mean we’re all out of ideas in terms of how to improve performance and security. In fact, Electrolysis has just set us up to do something we think will be really big.
We’re calling it Project Quantum.
Quantum is our effort to develop Mozilla’s next-generation web engine and start delivering major improvements to users by the end of 2017. If you’re unfamiliar with the concept of a web engine, it’s the core of the browser that runs all the content you receive as you browse the web. Quantum is all about making extensive use of parallelism and fully exploiting modern hardware. Quantum has a number of components, including several adopted from the Servo project.
The resulting engine will power a fast and smooth user experience on both mobile and desktop operating systems — creating a “quantum leap” in performance. What does that mean? We are striving for performance gains from Quantum that will be so noticeable that your entire web experience will feel different. Pages will load faster, and scrolling will be silky smooth. Animations and interactive apps will respond instantly, and be able to handle more intensive content while holding consistent frame rates. And the content most important to you will automatically get the highest priority, focusing processing power where you need it the most.
So how will we achieve all this?
Web browsers first appeared in the era of desktop PCs. Those early computers only had single-core CPUs that could only process commands in a single stream, so they truly could only do one thing at a time. Even today, in most browsers an individual web page runs primarily on a single thread on a single core.
But nowadays we browse the web on phones, tablets, and laptops that have much more sophisticated processors, often with two, four or even more cores. Additionally, it’s now commonplace for devices to incorporate one or more high-performance GPUs that can accelerate rendering and other kinds of computations.
One other big thing that has changed over the past fifteen years is that the web has evolved from a collection of hyperlinked static documents to a constellation of rich, interactive apps. Developers want to build, and consumers expect, experiences with zero latency, rich animations, and real-time interactivity. To make this possible we need a web platform that allows developers to tap into the full power of the underlying device, without having to agonize about the complexities that come with parallelism and specialized hardware.
And so, Project Quantum is about developing a next-generation engine that will meet the demands of tomorrow’s web by taking full advantage of all the processing power in your modern devices. Quantum starts from Gecko, and replaces major engine components that will benefit most from parallelization, or from offloading to the GPU. One key part of our strategy is to incorporate groundbreaking components of Servo, an independent, community-based web engine sponsored by Mozilla. Initially, Quantum will share a couple of components with Servo, but as the projects evolve we will experiment with adopting even more.
A number of the Quantum components are written in Rust. If you’re not familiar with Rust, it’s a systems programming language that runs blazing fast, while simplifying development of parallel programs by guaranteeing thread and memory safety. In most cases, Rust code won’t even compile unless it is safe.
We’re taking on a lot of separate but related initiatives as part of Quantum, and we’re revisiting many old assumptions and implementations. The high-level approach is to rethink many fundamental aspects of how a browser engine works. We’ll be re-engineering foundational building blocks, like how we apply CSS styles, how we execute DOM operations, and how we render graphics to your screen.
Quantum is an ambitious project, but users won’t have to wait long to start seeing improvements roll out. We’re going to ship major improvements next year, and we’ll iterate from there. A first version of our new engine will ship on Android, Windows, Mac, and Linux. Someday we hope to offer this new engine for iOS, too.
We’re confident Quantum will deliver significantly improved performance. If you’re a developer and you’d like to get involved, you can learn more about Quantum on the the Mozilla wiki, and explore ways that you can contribute. We hope you’ll take the Quantum leap with us.
Self Hosted WordPress.org vs. Free WordPress.com [Infograph]
Editorial StaffSeptember 30th, 2016
When starting out as a beginner, this question comes in everyone’s mind. Which one is better? Is it better to pick the Self Hosted WordPress.org, or is it better to go with Free WordPress.com? In this article, we provide you with an infographic that compares WordPress.com vs WordPress.org side by side with list of pros and cons. We also tell you in the end which one is our pick. Click on the image to see the full version of the Infographic.
Self Hosted WordPress.org vs. Free WordPress.com [Infograph]
Editorial StaffSeptember 30th, 2016
When starting out as a beginner, this question comes in everyone’s mind. Which one is better? Is it better to pick the Self Hosted WordPress.org, or is it better to go with Free WordPress.com? In this article, we provide you with an infographic that compares WordPress.com vs WordPress.org side by side with list of pros and cons. We also tell you in the end which one is our pick. Click on the image to see the full version of the Infographic.
Difference between self-hosted WordPress.org vs Free WordPress.com blog
Note: We have updated this infographic because there was a huge debate about the comparison. The goal of this infographic is to compare Self Hosted WordPress.org vs. FREE WordPress.com*. We were called out by many folks saying, WordPress.com offers CSS upgrades etc. etc. But apparently, we were not clear enough…
View original post 933 more words
WEB TECHNOLOGIST 