Tools like Travis CI and Netlify offer some pretty nifty features, like seamlessly deploying your GitHub Pages site when changes are pushed to its repository. Along with a static site generator like Hugo, keeping a blog up to date is pretty painless.

I’ve used Hugo to build my site for years, but until this past week I’d never hooked up my Pages repository to any deployment service. Why? Because using a tool that built my site before deploying it seemed to require having the whole recipe in one place - and if you’re using GitHub Pages with the free version of GitHub, that place is public. That means that all my three-in-the-morning bright ideas and messy unfinished (and unfunny) drafts would be publicly available - and no amount of continuous convenience was going to convince me to do that.

So I kept things separated, with Hugo’s messy behind-the-scenes stuff in a local Git repository, and the generated public/ folder pushing to my GitHub Pages remote repository. Each time I wanted to deploy my site, I’d have to get on my laptop and hugo to build my site, then cd public/ && git add . && git commit… etc etc. And all was well, except for the nagging feeling that there was a better way to do this.

I wrote another article a little while back about using GitHub and Working Copy to make changes to my repositories on my iPad whenever I’m out and about. It seemed off to me that I could do everything except deploy my site from my iPad, so I set out to change that.

A couple three-in-the-morning bright ideas and a revoked access token later (oops), I now have not one but two ways to deploy to my public GitHub Pages repository from an entirely separated, private GitHub repository. In this post, I’ll take you through achieving this with Travis CI or using Netlify and Make.

There’s nothing hackish about it - my public GitHub Pages repository still looks the same as it does when I pushed to it locally from my terminal. Only now, I’m able to take advantage of a couple great deployment tools to have the site update whenever I push to my private repo, whether I’m on my laptop or out and about with my iPad.

#YouDidNotPushFromThere

This article assumes you have working knowledge of Git and GitHub Pages. If not, you may like to spin off some browser tabs from my articles on using GitHub and Working Copy and building a site with Hugo and GitHub Pages first.

Let’s do it!

Private-to-public GitHub Pages deployment with Travis CI

Travis CI has the built-in ability (♪) to deploy to GitHub Pages following a successful build. They do a decent job in the docs of explaining how to add this feature, especially if you’ve used Travis CI before… which I haven’t. Don’t worry, I did the bulk of the figuring-things-out for you.

• Travis CI gets all its instructions from a configuration file in the root of your repository called .travis.yml
• You need to provide a GitHub personal access token as a secure encrypted variable, which you can generate using travis on the command line
• Once your script successfully finishes doing what you’ve told it to do (not necessarily what you want it to do but that’s a whole other blog post), Travis will deploy your build directory to a repository you can specify with the repo configuration variable.

Setting up the Travis configuration file

Create a new configuration file for Travis with the filename .travis.yml (note the leading “.”). These scripts are very customizable and I struggled to find a relevant example to use as a starting point - luckily, you don’t have that problem!

Here’s my basic .travis.yml:

git:
 depth: false

env:
 global:
 - HUGO_VERSION="0.54.0"
 matrix:
 - YOUR_ENCRYPTED_VARIABLE

install:
 - wget -q https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz
 - tar xf hugo_${HUGO_VERSION}_Linux-64bit.tar.gz
 - mv hugo ~/bin/

script:
 - hugo --gc --minify

deploy:
 provider: pages
 skip-cleanup: true
 github-token: $GITHUB_TOKEN
 keep-history: true
 local-dir: public
 repo: gh-username/gh-username.github.io
 target-branch: master
 verbose: true
 on:
 branch: master

This script downloads and installs Hugo, builds the site with the garbage collection and minify flags, then deploys the public/ directory to the specified repo - in this example, your public GitHub Pages repository. You can read about each of the deploy configuration options here.

To add the GitHub personal access token as an encrypted variable, you don’t need to manually edit your .travis.yml. The travis gem commands below will encrypt and add the variable for you when you run them in your repository directory.

First, install travis with sudo gem install travis.

Then generate your GitHub personal access token, copy it (it only shows up once!) and run the commands below in your repository root, substituting your token for the kisses:

travis login --pro --github-token xxxxxxxxxxxxxxxxxxxxxxxxxxx
travis encrypt GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxx --add env.matrix

Your encrypted token magically appears in the file. Once you’ve committed .travis.yml to your private Hugo repository, Travis CI will run the script and if the build succeeds, will deploy your site to your public GitHub Pages repo. Magic!

Travis will always run a build each time you push to your private repository. If you don’t want to trigger this behavior with a particular commit, add the skip command to your commit message.

Yo that’s cool but I like Netlify.

Okay fine.

Deploying to a separate repository with Netlify and Make

We can get Netlify to do our bidding by using a Makefile, which we’ll run with Netlify’s build command.

Here’s what our Makefile looks like:

SHELL:=/bin/bash
BASEDIR=$(CURDIR)
OUTPUTDIR=public
.PHONY: all
all: clean get_repository build deploy
.PHONY: clean
clean:
@echo "Removing public directory"
rm -rf $(BASEDIR)/$(OUTPUTDIR)
.PHONY: get_repository
get_repository:
@echo "Getting public repository"
git clone https://github.com/gh-username/gh-username.github.io.git public
.PHONY: build
build:
@echo "Generating site"
hugo --gc --minify
.PHONY: deploy
deploy:
@echo "Preparing commit"
@cd $(OUTPUTDIR) \
 && git config user.email "you@youremail.com" \
 && git config user.name "Your Name" \
 && git add . \
 && git status \
 && git commit -m "Deploy via Makefile" \
 && git push -f -q https://$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master
@echo "Pushed to remote"

To preserve the Git history of our separate GitHub Pages repository, we’ll first clone it, build our new Hugo site to it, and then push it back to the Pages repository. This script first removes any existing public/ folder that might contain files or a Git history. It then clones our Pages repository to public/, builds our Hugo site (essentially updating the files in public/), then takes care of committing the new site to the Pages repository.

In the deploy section, you’ll notice lines starting with &&. These are chained commands. Since Make invokes a new sub-shell for each line, it starts over with every new line from our root directory. To get our cd to stick and avoid running our Git commands in the project root directory, we’re chaining the commands and using the backslash character to break long lines for readability.

By chaining our commands, we’re able to configure our Git identity, add all our updated files, and create a commit for our Pages repository.

Similarly to using Travis CI, we’ll need to pass in a GitHub personal access token to push to our public GitHub Pages repository - only Netlify doesn’t provide a straightforward way to encrypt the token in our Makefile.

Instead, we’ll use Netlify’s Build Environment Variables, which live safely in our site settings in the Netlify app. We can then call our token variable in the Makefile. We use it to push (quietly, to avoid printing the token in logs) to our Pages repository by passing it in the remote URL.

To avoid printing the token in Netlify’s logs, we suppress recipe echoing for that line with the leading @ character.

With your Makefile in the root of your private GitHub repository, you can set up Netlify to run it for you.

Setting up Netlify

Getting set up with Netlify via the web UI is straightforward. Once you sign in with GitHub, choose the private GitHub repository where your Hugo site lives. The next page Netlify takes you to lets you enter deploy settings:

You can specify the build command that will run your Makefile (make all for this example). The branch to deploy and the publish directory don’t matter too much in our specific case, since we’re only concerned with pushing to a separate repository. You can enter the typical master deploy branch and public publish directory.

Under “Advanced build settings” click “New variable” to add your GitHub personal access token as a Build Environment Variable. In our example, the variable name is GITHUB_TOKEN. Click “Deploy site” to make the magic happen.

If you’ve already previously set up your repository with Netlify, find the settings for Continuous Deployment under Settings > Build & deploy.

Netlify will build your site each time you push to the private repository. If you don’t want a particular commit to trigger a build, add [skip ci] in your Git commit message.

Same same but different

One effect of using Netlify this way is that your site will be built in two places: one is the separate, public GitHub Pages repository that the Makefile pushes to, and the other is your Netlify site that deploys on their CDN from your linked private GitHub repository. The latter is useful if you’re going to play with Deploy Previews and other Netlify features, but those are outside the scope of this post.

The main point is that your GitHub Pages site is now updated in your public repo. Yay!

Go forth and deploy fearlessly

I hope the effect of this new information is that you feel more able to update your sites, wherever you happen to be. The possibilities are endless - at home on your couch with your laptop, out cafe-hopping with your iPad, or in the middle of a first date on your phone. Endless!

Don’t do stuff on your phone when you’re on a date. Not if you want a second one, anyway.

One of the things we find ourselves doing more and more of at Reclaim Hosting is managed hosting, in particular for WordPress Multisite (WPMS). In the end was the beginning for this blog. So, I was on a call last week were the discussion around running multiple, independent WPMS instances versus one WPMS instance with multiple networks, i.e. sites.stateu.org and courses.stateu.org represent two functioning WPMS instances using subdomains (or subdirectories) such as mysite.sites.stateu.org or mycourse.courses.stateu.org that both point and share one set of core WordPress files. I experimented with this over 10 years ago by running a WPMS (then called WPMU) service for Longwood University off the core WordPress files of UMW Blogs. I thought it would be revolutionary for the ability to share infrastructure across Virginia public institutions of higher ed, but not so much. That said, I was glad to see Curtiss Grymala to take the whole idea of multi-networks to the next level for UMW’s main website.

Anyway, enough about the past, that was then, this is now …. for now. The question is why would you run several independent WPMS instances with distinct core files versus running multiple instances of WPMS off of one shared set of files, plugins, themes, etc.? For me the value of running everything off one shared set of files was shared themes, plugins, and updates that make management easier than across numerous separate installs.*  Another benefit was a single space for site/user administration between networks. Additionally, managing single sign-on through one instance should prove a bit easier for setup, but will need to double-check on this one. I also know you can have various portals for each WPMS network mapped on a single set of files, so it will not be confusing for the users, for them the fact they share core files will be invisible. So, in this regard the choice comes down to whether or not consolidation makes sense for the WPMS admin, which is often a question of convenience.

But there may be some practical reasons not to use a multi-network setup. Like, for example, if you are planing on running thousands of sites on each of these WPMS instances you may want to keep them separate given scaling issue with the WPMS database.** Having three WPMS instances share core files means if one goes down, they all go down, which can be an issue. Also, if you have an existing WPMS site you want to incorporate into an existing multi-network setup it may get tricky depending on whether there are shared users across the various instances of WPMS that you’re combining. I will have to do more research here, and would love to know about anyone’s experience in this regard, but I imagine users across a multi-network instance would need to be able to access the various networks with the same email/username across networks for the sake of both convenience and single sign-on (which are often one in the same).

Which raises another question that I’m unsure of,  if users sign-in through one network of a multi-network setup can they cleanly move between sites on different networks? I’m wondering if keeping single sign-on and users separate in this instance may prove less problematic in the long run. I’ll be working through these scenarios this week, but wanted to post this here cause I know a few folks have experience with running multi-networks on bit sites and wanted to be sure I was not overlooking any major red flags before making some recommendations.

*It also allows you to share any premium themes or plugins across one instance.

**Although if this is the case you will have to shard databases anyway, so one could argue it would be easier to do that for one instance rather than many. 

In honor of everyday being Earth Day and the importance of sustainable living, here at Blix Bikes we want to help spread the word about alternative transportation. You can go many places and take many things with a Blix electric bike. 

One mom tested the Packa for the day with two kids tagging along on daily chores, lunch runs, and beach days. Learn how adding an electric bike to your lifestyle can both bring back the fun and reduce your carbon footprint.

After a Packa filled day riding to lunch, the beach, the grocery store, and coffee, Kimberly was impressed with how easily she could do everything she would have done in her car on the Packa. She says, "it was so much fun!" Kimberly was also pleased with how she was able to conquer hills with ease. On her ride, it was "super hilly from [their] house over to Gayle's and the beach," but, "it was so magical having the Blix." With the pedal assist, Kimberly "didn't get tired going up the hills even with two kids behind [her]." By spending a day on the electric bike and instead of in the car, Kimberly reduced her carbon footprint while also adding some fun to both her daughters' and her own day!

Thank you to Kimberly and her daughters for replacing their car with the Packa for a day! 

_____________________

According to the U.S Department of Transportation, on average, Americans drive 29 miles per day with 45% of these trips being for groceries and other errands and 15% related to commuting. Additionally, due to traffic and overcrowding, it will take an average of 55 minutes to reach their destinations. The CO2 emissions and amount of gas required for these trips add up and negatively effect our environment! By replacing a car with an electric bike, you will spend less time behind the wheel, reduce your CO2 emissions, and save on gas money!

In the past, one of the main concerns with replacing your car with an electric bike was the inability to carry everything needed. With the Blix Packa, not only will you shorten the time spent in the car running daily errands, you will be able to reach your destinations packed with cargo (including kids). The Packa has a payload of 400lbs meaning you can carry groceries, packages, sport equipment, or pack for a beach day. Its dual-battery capacity gives you a range up to 70 miles per charge and with 5 levels of pedal assist and a throttle you can reach up to 20mph. Plus, you can personalize your Packa by mixing and matching Blix accessories to fit your cargo needs. 

Happy Earth Day from the Blix team!

                                                                                                          

Follow us for more great stories!

Facebook

Instagram

Apple now promises next-day turnaround repairs and pickup for MacBook, MacBook Air and MacBook Pro keyboard repairs, according to a report from MacRumors. 

The publication states that Apple previously sent MacBook Pro laptops with broken keyboards out to repair depots. However, the company is now reportedly telling Genius Bar employees that “most” keyboard-related repairs will be handled in-store “until further notice.”

Further, MacRumors claims that “additional service parts have been shipped to stores to support the increased volume”

While the third-generation Butterfly keyboard featured in the MacBook Pro (2018) and MacBook Air (2018) was reportedly designed to solve the reliability issues of its predecessors, it doesn’t seem to have solved the problem. The hardware malfunction typically involves keys producing two letters or not working at all.

The third-generation Butterfly keyboard features a silicon membrane between the keys that is designed to prevent debris from getting in the key’s mechanism. Apple claims this design change was made so the keys would be quieter. That said, many believe the subtle redesign’s goal was to solve the keyboard’s reliability problems.

I’ve run into this issue a number of times with the multiple MacBook Pro laptops I’ve used over the last few years. I typically solve the issue with a can of compressed air, screen cleaner and by repeatedly pressing the key. That said, given the price of Apple’s laptops, keyboard reliability problems shouldn’t be something users are forced to deal with.

Following the publication of a recent column by The Wallstreet Journal’s Joanna Stern, Apple released a statement regarding the MacBook Pro’s keyboard issues for the first time.

“We are aware that a small number of users are having issues with their third-generation butterfly keyboard and for that we are sorry,” an Apple spokesperson told Stern in a statement. “The vast majority of Mac notebook customers are having a positive experience with the new keyboard.”

Source: MacRumors 

The post Apple reportedly commits to next-day repairs for MacBook Pro keyboard appeared first on MobileSyrup.

The worst part of any software project is setting up a development environment. It’s by far the biggest barrier for anyone trying to get started learning to code. I’ve been a developer for more than twenty years and I still feel the pain any time I want to do something new.

Glitch is the most promising attempt I’ve ever seen at tackling this problem. It provides an entirely browser-based development environment that allows you to edit code, see the results instantly and view and remix the source code of other people’s projects.

It’s developed into a really fun, super-creative community and a fantastic resource for people looking to get started in the ever-evolving world of software development.

This evening I decided to get Datasette running on it. I’m really impressed with how well it works, and I think Glitch provides an excellent environment for experimenting with Datasette and related tools.

TLDR version: visit https://glitch.com/edit/#!/remix/datasette-csvs right now, drag-and-drop in a CSV file and watch it get served by Datasette on Glitch just a few seconds later.

Running Python on Glitch

The Glitch documentation is all about Node.js and JavaScript, but they actually have very solid Python support as well.

Every Glitch project runs in a container that includes Python 2.7.12 and Python 3.5.2, and you can use pip install --user or pip3 install --user to install Python dependencies.

The key to running non-JavaScript projects on Glitch is the glitch.json file format. You can use this to specify an install script, which sets up your container, and a start script, which starts your application running. Glitch will route HTTP traffic to port 3000, so your application server needs to listen on that port.

This means the most basic Glitch project to run Datasette looks like this:

https://datasette-basic.glitch.me/ (view source)

It contains a single glitch.json file:

{
    "install": "pip3 install --user datasette",
    "start": "datasette -p 3000"
}

This installs Datasette using pip3, then runs it on port 3000.

Since there’s no actual data to serve, this is a pretty boring demo. The most interesting page is this one, which shows the installed versions of the software:

https://datasette-basic.glitch.me/-/versions

Something more interesting: datasette-csvs

Let’s build one with some actual data.

My csvs-to-sqlite tool converts CSV files into a SQLite database. Since it’s also written in Python we can run it against CSV files as part of the Glitch install script.

Glitch provides a special directory called .data/ which can be used as a persistent file storage space that won’t be cleared in between restarts. The following "install" script installs datasette and csvs-to-sqlite, then runs the latter to create a SQLite database from all available CSV files:

{
    "install":  "pip3 install --user datasette csvs-to-sqlite && csvs-to-sqlite *.csv .data/csv-data.db",
    "start": "datasette .data/csv-data.db -p 3000"
}

Now we can simply drag and drop CSV files into the root of the Glitch project and they will be automatically converted into a SQLite database and served using Datasette!

We need a couple of extra details. Firstly, we want Datasette to automatically re-build the database file any time a new CSV file is added or an existing CSV file is changed. We can do that by adding a "watch" block to glitch.json:

"watch": {
    "install": {
        "include": [
            "\\.csv$"
        ]
    }
}

This ensures that our "install" script will run again any time a CSV file changes.

Let’s tone down the rate at which the scripts execute, by using throttle to set the polling interval to once a second:

"throttle": 1000

The above almost worked, but I started seeing errors if I changed the number of columns in a CSV file, since doing so clashed with the schema that had already been created in the database.

My solution was to add code to the install script that would delete the SQLite database file before attempting to recreate it - using the rm ... || true idiom to prevent Glitch from failing the installation if the file it attempted to remove did not already exist.

My final glitch.json file looks like this:

{
  "install": "pip3 install --user datasette csvs-to-sqlite && rm .data/csv-data.db || true && csvs-to-sqlite *.csv .data/csv-data.db",
  "start": "datasette .data/csv-data.db -p 3000 -m metadata.json",
  "watch": {
    "install": {
      "include": [
        "\\.csv$"
      ]
    },
    "restart": {
      "include": [
        "^metadata.json$"
      ]
    },
    "throttle": 1000
  }
}

I also set it up to use Datasette’s metadata.json format, and automatically restart the server any time the contents of that file changes.

https://datasette-csvs.glitch.me/ (view source) shows the results, running against a simple example.csv file I created.

Remixing!

Here’s where things get really fun: Glitch projects support “remixing”, whereby anyone can click a link to create their own editable copy of a project.

Remixing works even if you aren’t logged in to Glitch! Anonymous projects expire after five days, so be sure to sign in with GitHub or Facebook if you want to keep yours around.

Try it out now: Visit https://glitch.com/edit/#!/remix/datasette-csvs to create your own remix of my project. Then drag a new CSV file directly into the editor and within a few seconds Datasette on Glitch will be up and running against a converted copy of your file!

Limitations

The Glitch help center article What technical restrictions are in place? describes their limits. Most importantly, projects are limited to 4,000 requests an hour - and there’s currently no way to increase that limit. They also limit projects to 200MB of disk space - easily enough to get started exploring some interesting CSV files with Datasette.

Next steps

I’m delighted at how easy this was to setup, and how much power the ability to remix these Datasette demos provides. I’m tempted to start creating remixable Glitch demos that illustrate other aspects of Datasette’s functionality such as plugins or full-text search.

Glitch is an exceptionally cool piece of software. I look forward to seeing their Python support continue to evolve.

A flaw of communities is the more emotional the post, the more persuasive it seems.

Angrier posts are more likely to be accepted as true by new members and attract more likes/comments (thus appearing at the top of the community for all members).

It doesn’t take long for members to realise that the angrier they post, the more attention they get.

If you let angry posts stand, your community soon becomes filled with them.

Two approaches can help here. The first is to have a rule or create a norm, against posting angry (frame it as posting unprofessionally).

If the post is clearly provocative or incites further anger, you need to address the issue directly with the member and remove the post. Members can be critical as much as they like, but they can’t use flagrantly angry words to incite anger from others.

The second is to copy Denise’s approach and have a group of members who step in with a friendly tone and prevent issues from escalating.

Ooo, bubbles... It's not the most visually efficient method, but it's one of the more visually satisfying ones. Read More

Language support on Glitch: a list

This is really useful: it's essentially "Glitch: the missing manual" for running languages other than JavaScript. The Glitch community forums are a gold mine of useful information like this.

Via @ann_arcana

You will need to provide your name and email to access this free eBook (this is what I call a 'spamwall') but in this cases the trade is probably worthwhile. The book offers a very accessible introduction to graph theory and graph-based data processing that clearly illustrates the difference between this and statistics-based modeling. There is some practical instruction concerning the installation of Apache Sp[ark and Neo4j which you can follow of skip. Then the meat of the book: graph algorithms - even if you don't work with these directly, the chapters offer a good overview of the sorts of things graph algorithm,s can do (pathfinding, centrality, community detection, more).

Research in social media in educational institutions has shown "continuing and expanding use in campus based, distance and blended learning contexts and, at least, preliminary results suggesting significant educational benefit." At the same time, writes Terry Anderson, there is growing awareness of the risks. For example, " Some critical reviewers suggest that social media is not conducive to education as it contains an explicit bias towards conviviality and homogeneity and lacks the critical components of disagreement and discourse." The paper is a straightforward discussion of the topic, but near the end - almost as an afterthought - is a mention of decentralized social media and the observation that "Verborgh (2019) shows how this individual ownership of data, stored in personal owned data pods is differentiated from the current model."

The new video-based social network from the creator of Vine called Byte is in private beta indicating that it’s on the verge of releasing, according to a TechCrunch report. 

The new app has recently sent out 100 invites to people to be part of its closed beta, reads the report. On top of this the creator, Dom Hofmann, previously stated that he is targeting a spring 2019 launch for the platform.

the byte beta we’ve been running with friends and family *feels* exactly like the vine friends and family beta, down to the weird but appealing randomness of the videos. that’ll change as we expand, but it’s a pretty good sign pic.twitter.com/rBbQrNtTJ7

— dom hofmann (@dhof) April 22, 2019

Ideally, this means that the rest of the world is going to get to use the app sometime soon.

On Byte’s forums, the platform says that the app is currently A/B testing features like “the sign-up process, global timeline, posting from the in-app camera, liking, and commenting” among others.

The company is coming into a much more competitive space than Vine died in. Tik Tok is blowing up among younger audiences, while Snapchat, Facebook and Instagram are all heavily invested in video ‘Stories.’

Hoffman told TechCrunch that he thinks that Tik Tok is an evolutionary step past what Vine did and he’s hoping that Byte can go down a different road. As a result, he feels that the two apps won’t compete directly.

Source: Byte Fourms, TechCrunch

The post Social network Vine is about to make a return as Byte appeared first on MobileSyrup.

Was früher als „Basic Plan“ bezeichnet wurde, wird jetzt „kein Abonnement“ genannt. Wenn Sie über eine kabellose Arlo Kamera, eine Arlo Pro, Pro 2, Go, Q, Q Plus oder Arlo Baby Kamera verfügen, profitieren Sie weiterhin von allen Vorteilen, die beim Kauf Ihrer Kamera enthalten waren, einschließlich eines kostenlosen Cloud-Speichers für 7 Tage.

Dieser Basic Plan ist ein Super-Deal. Man bekommt Cloud Recording für eine ganze Woche, ohne laufende Kosten. Ich habe mich schon immer gewundert wie sich das rechnet. Und damit ist jetzt auch Schluss. Für die Arlo Ultras gibt es das nicht mehr:

Arlo Ultra Kits umfassen derzeit ein einjähriges Abonnement für Arlo Smart Premier. Wenn Sie andere Arlo Kameras besitzen und ein Arlo Ultra Kit erwerben, können Sie Arlo Smart Premier ein Jahr lang für alle Ihre Arlo Kameras (bis zu 10) verwenden. Wenn das einjährige Abonnement abläuft, haben Sie die Möglichkeit, sich für denselben Plan anzumelden oder einen der anderen Arlo Smart Plan auszuwählen.

Mit 9 Euro im Monat geht dieser Smart Premier Service ziemlich ins Geld. Ich empfehle deshalb eine Arlo Pro 2 zu kaufen, so lange es die noch gibt.

Die "Nicht-Ultras" fallen wieder auf den alten Basic Plan zurück, aber die Ultra hat kein Cloud Recording ohne Abo.

More >

Last year, mobile wireless providers saw the largest increase in subscriber counts since 2011, according to a report released on Monday by the Convergence Research Group.

The group estimates that 1.49 million subscribers were added in 2018 in its Canadian Couch Potato analysis. At the same time, wireless revenues grew by five percent to $21.2 billion, and Convergence forecasts that to continue into 2019.

Unsurprisingly, the report indicates that revenues and subscriber counts continue to fall for traditional Canadian television providers.

Both metrics declined by an estimated two percent in 2018, said the report, with traditional TV provider revenue coming in around $8.58 billion, as well as seeing a loss of approximately 210,000 subscribers. The research group also predicted that in 2019, the television business will see another drop of about 253,000 subscribers.

On the flip side, over-the-top (OTT) services like Netflix continued to grow in Canada with an estimated 33 percent jump to $1.12 billion in revenues last year, and a predicted $1.51 billion in 2019. Like last year, Convergence thinks that by year-end 2020, OTT subscriber numbers will exceed those with traditional television.

“American programmer direct to consumer OTT plays have started to impact with CBS All Access going direct and not selling select series to Canadian distributors, NBCU’s hayu up against its linear Canadian distributors, and Discovery’s launch of GolfTV OTT in Canada,” said the report. “We expect more entries as programmers expand their OTT platforms globally.”

At the same time, it’s not all bad news for Canada’s television providers, as their residential internet business continues to enjoy growth. Subscriber addition estimates topped 387,000 and revenue increased eight percent to $8.68 billion in 2018.

Similar increases in broadband subscribers are expected for next year as well.

These numbers were derived from analysis of 24 streaming services.

Source: Convergence Research Group

The post Mobile subs growth in 2018 was biggest in almost a decade, says report appeared first on MobileSyrup.

After the bombings, Sri Lanka’s government shut down Facebook, WhatsApp, Instagram and another social application, Viber. Apparently these applications are toxic in crises. (Also at all other times, but especially in crises.) According to government spokesman Harindra B. Dassanayake, as quoted in the New York Times, “These platforms are banned because they were spreading hate … Continued

The post Sri Lanka shuts down Facebook. Can we stop the spread of hate permanently? appeared first on without bullshit.