Today I learned things that I think every environmentalist and investment manager should know: A coherent argument that we are more or less at Peak Oil. Not the Nineties version, which worried that we might be running out of fossil fuels, but rather that global human petroleum demand is about at its all-time peak and about to start drifting down. Some of the key data points involve electric cars, which I care a lot about, and China, which is always interesting.

The effects are likely not enough to avert the oncoming global-warming disaster, but there are grounds for optimism about reducing its devastation. However, this will very likely tear the guts out of the global petroleum business.

What happened was, I ran across an interesting Twitter thread starting with the bold claim that the internal combustion engine’s future had been killed and that the coming energy transition would pay for itself. It was compelling and I gave it a retweet, noting that people who live in an environmentalist-green bubble (for example, me) need to be skeptical about things that we’d like to be true. And so we should.

But I was intrigued enough to buy a 105-page PDF called Oil Fall; you can too, for $9, from its author Gregor Macdonald. If you care about these subjects, you should. I sure enjoyed it.

(If you buy it: While you can read it on a Kindle, don’t try, the type’s too small. It might be OK on an iPad. Or you can just pop it open in Preview on a Mac or whatever the Windows equivalent is. It’s nicely typeset and illustrated; the print isn’t dense and the 105 pages go by fast.)

The larger stories — of the increasingly-threatening specter of climate change, and the growing viability of renewable energy — aren’t new at all. But there’s one piece of new news: The shocking surge of Electric Vehicles (hereinafter EVs) in China in 2018, concurrent with a decline in overall vehicle sales there. Probably 1.2 million or so EVs were sold, surging to comprise 7% of all sales toward the end of the year. Here are a couple of instructive links: CleanTechnica and Quartz.com.

The argument in Oil Fall spends a lot of time on electric cars, since they are at a point of surprisingly high leverage in the global energy economy.

I’m not going to replicate the Oil Fall narrative, but here’s a quick sort-of outline.

1. Los Angeles as a case study in EV adoption. It’s not the US leader (that’d be the Bay Area) but it’s got huge leverage.

2. The politics and economics of renewable energy in California and across the US.

3. The special leverage of the EV on the energy economy.

4. The structure of China’s (historically coal-dominated) energy economy.

5. Why China is crucial to the future price of fossil fuel

6. The timing of the peak in global oil demand.

7. Efficiencies and inefficiencies in fossil and renewable energy sources.

8. The issue of energy storage.

9. Economic cost of transition to renewables; estimates have been around 2% of GDP, but Macdonald thinks it’ll be closer to zero, or even negative. That’s what Alexandria Ocasio-Cortez and the young US progressives are arguing with their “Green New Deal” proposal.

10. Global-warming prospects.

On the writing

I don’t know much about Macdonald. His resume sounds respectable, and I quote: “He has written for Nature, The Economist Intelligence Unit, The Financial Times of London, The Harvard Business Review, Atlantic Media’s Route Fifty, The Petroleum Economist, and Talking Points Memo.”

The text is well-supplied with numbers and supporting infographics. He is careful to address, for each key point, the objections to his reasoning and alternative scenarios that arise in the case that he’s wrong. I didn’t check his numbers exhaustively, but every one of those that I did try to verify checked out.

The style is that of a professional journalist: Not colorful but extremely clear, readable, and full of named real-world examples illustrating his arguments.

I’m going to dig a little deeper into a couple of points that were new to me and resonated.

On EVs and storage

Anybody who’s a renewable-energy fan needs to have thought a lot about energy storage. The sun only shines during the daytime and sometimes even prevailing winds don’t blow. Macdonald goes deep on the subject, and offered a pretty compelling argument that there are plausible market-driven solutions to meet storage needs.

One part of the argument involves electric cars, and is obvious once you think of it. Planet-wide, we are now building millions per year, and every one is built around a battery ranging in capacity between 20 and 90KWh. Do some multiplication and you get a damn big energy-storage capability, made up of a huge number of independently-owned consumer products. They aren’t terribly fussy what time of day you charge them, they are network-connected, and managing the network to charge them when the capacity is most available feels like a straightforward application of the sort that I work on every day.

On EVs and negawatts

That term “negawatt” was coined way back in 1985 by Amory Lovins, one of the original big energy-policy thinkers. He did the math and showed that the cheapest way to get more power while doing less damage was simply to cut waste. And it’s worked: Our houses are better insulated now, our cars get more mileage, and our appliances run cooler and smarter.

But the global energy-efficiency picture is still terrible. The whole fossil-combustion ecosystem wastes something in the neighborhood of 50% of the available energy. It’s not uniform: For example, a modern natural-gas based generator wastes less. But internal-combustion vehicles waste a lot more, even today the figure is in the 70%-wasted range.

EVs, on the other hand, turn electrons into kilometers at an efficiency well over 90%. Of course, that doesn’t help if you’re using electricity that was generated in a fossil-fueled plant; but traveling in a renewable-fed EV is a rich source of negawatts.

To quote Macdonald: “But, the loss is quite a bit worse with every gallon of petrol poured into an internal combustion engine. Indeed, if your goal was to waste as much energy as possible, you could do no better than to feed gasoline into a billion vehicles, each with their own separate engine, with multiple surfaces from which heat can rise.”

Is oil over?

Of course not, don’t be silly. Everyone agrees that coal is “over” and yet its usage hasn’t plummeted, it’s just been drifting down for a long time, with a temporary spike as China industrialized. Petroleum remains useful in a huge number of industrial chemical processes, and in certain particularly energy-intensive transportation applications, like heavy trucks and probably almost all aviation. We don’t need to stamp out oil to save the planet, just burn less.

My own particular guess is that natural gas is going to be strategic. It’s relatively energy-dense, straightforward to extract and transport, and carbon-light; it feels like a good fit for filling in renewable-energy gaps.

On investing

There’s a trend where “ethical investors” try to steer capital away from the petroleum industries, and I broadly approve, mostly due to fear of climate change. But if Macdonald is right (and he’s pretty convincing) this is also a good way to remove a major source of risk from your portfolio.

Don’t say I didn’t warn you.

Last week I blogged about writing code that is easy to delete, drawing on some great lines from an old 'programming is terrible' post. Here's another passage from @tef's post that's worth thinking more about:

Step 1: Copy-paste code

Building reusable code is something that's easier to do in hindsight with a couple of examples of use in the code base, than foresight of ones you might want later. On the plus side, you're probably re-using a lot of code already just by using the file-system, why worry that much? A little redundancy is healthy.

It's good to copy-paste code a couple of times, rather than making a library function, just to get a handle on how it will be used. Once you make something a shared API, you make it harder to change.

There's not a great one-liner in there, but these paragraphs point to a really important lesson, one that we programmers sometimes have a hard time learning. We are told so often "don't repeat yourself" that we come to think that all repetition is the same. It's not.

One use of repetition is in avoiding what @tef calls, in another 'programming is terrible' post, "preemptive guessing". Consider the creation of a new framework. Oftentimes, designing a framework upfront doesn't work very well because we don't know the domain's abstractions yet. One of the best ways to figure out what they are is to write several applications first, and let framework fall out the applications. While doing this, repetition is our friend: it's most useful to know what things don't change from one application to another. This repetition is a hint on how to build the framework we need. I learned this technique from Ralph Johnson.

I use and teach a similar technique for programming in smaller settings, too. When we see two bits of code that resemble one another, it often helps to increase the duplication in order to eliminate it. (I learned this idea from Kent Beck.) In this case, the goal of the duplication is to find useful abstractions. Sometimes, though, code duplication is really a hint to think differently about a problem. Factoring out a function or class -- finding a new abstraction -- may be incidental to the learning that takes place.

For me, this line from from the second programming-is-terrible post captures this idea perfectly:

... duplicate to find the right abstraction first, then deduplicate to implement it.

My spell checker objects to the word "deduplicate", but I'll allow it.

All of these ideas taken together are the reason that I think copy-and-paste gets an undeservedly bad name. Used properly, it is a valuable programming technique -- essential, really. I've long wanted to write a Big Ball of Mud-style paper about copy-and-paste patterns. There are plenty of good reasons why we write repetitive code and, as @tef says in the two posts I link to above, sometimes leaving duplication in your code is the right thing to do.

One final tribute to repetition for now. While researching this blog post, I ran across a blog entry of mine from October 2016. Apparently, I had just read @tef's Write code that is easy to delete... post and felt an undeniable urge to quote and comment on it. If you read that 2016 post, you'll see that my Writing code that is easy to delete post from last week duplicates it in spirit and, in a few cases, even the details. I swear that I read @tef's post again last week and wrote the new blog entry from scratch, with no memory of the 2016 events. I am perfectly happy with this second act. Sometimes, ideas circle through our brains again, changing us in imperceptible ways. As @tef says, a little redundancy is healthy.

Originating in a thesis, REST is an attempt to explain what makes the browser distinct from other networked applications.

You might be able to imagine a few reasons why: there’s tabs, there’s a back button too, but what makes the browser unique is that a browser can be used to check email, without knowing anything about POP3 or IMAP.

Although every piece of software inevitably grows to check email, the browser is unique in the ability to work with lots of different services without configuration—this is what REST is all about.

HTML only has links and forms, but it’s enough to build incredibly complex applications. HTTP only has GET and POST, but that’s enough to know when to cache or retry things, HTTP uses URLs, so it’s easy to route messages to different places too.

Unlike almost every other networked application, the browser is remarkably interoperable. The thesis was an attempt to explain how that came to be, and called the resulting style REST.

REST is about having a way to describe services (HTML), to identify them (URLs), and to talk to them (HTTP), where you can cache, proxy, or reroute messages, and break up large or long requests into smaller interlinked ones too.

How REST does this isn’t exactly clear.

The thesis breaks down the design of the web into a number of constraints—Client-Server, Stateless, Caching, Uniform Interface, Layering, and Code-on-Demand—but it is all too easy to follow them and end up with something that can’t be used in a browser.

REST without a browser means little more than “I have no idea what I am doing, but I think it is better than what you are doing.”, or worse “We made our API look like a database table, we don’t know why”. Instead of interoperable tools, we have arguments about PUT or POST, endless debates over how a URL should look, and somehow always end up with a CRUD API and absolutely no browsing.

There are some examples of browsers that don’t use HTML, but many of these HTML replacements are for describing collections, and as a result most of the browsers resemble file browsing more than web browsing. It’s not to say you need a back and a next button, but it should be possible for one program to work with a variety of services.

For an RPC service you might think about a curl like tool for sending requests to a service:

$ rpctl http://service/ describe MyService
methods: ...., my_method

$ rpctl http://service/ describe MyService.my_method
arguments: name, age

$ rpctl http://service/ call MyService.my_method --name="James" --age=31
Result:
   message: "Hello, James!"

You can also imagine a single command line tool for a databases that might resemble kubectl:

$ dbctl http://service/ list ModelName --where-age=23
$ dbctl http://service/ create ModelName --name=Sam --age=23
$ ...

Now imagine using the same command line tool for both, and using the same command line tool for every service—that’s the point of REST. Almost.

$ apictl call MyService:my_method --arg=...
$ apictl delete MyModel --where-arg=...
$ apictl tail MyContainers:logs --where ...
$ apictl help MyService

You could implement a command line tool like this without going through the hassle of reading a thesis. You could download a schema in advance, or load it at runtime, and use it to create requests and parse responses, but REST is quite a bit more than being able to reflect, or describe a service at runtime.

The REST constraints require using a common format for the contents of messages so that the command line tool doesn’t need configuring, require sending the messages in a way that allows you to proxy, cache, or reroute them without fully understanding their contents.

REST is also a way to break apart long or large messages up into smaller ones linked together—something far more than just learning what commands can be sent at runtime, but allowing a response to explain how to fetch the next part in sequence.

To demonstrate, take an RPC service with a long running method call:

class MyService(Service):
    @rpc()
    def long_running_call(self, args: str) -> bool:
        id = third_party.start_process(args)
        while third_party.wait(id):
            pass
        return third_party.is_success(id)

When a response is too big, you have to break it down into smaller responses. When a method is slow, you have to break it down into one method to start the process, and another method to check if it’s finished.

class MyService(Service):
    @rpc()
    def start_long_running_call(self, args: str) -> str:
         ...
    @rpc()
    def wait_for_long_running_call(self, key: str) -> bool:
         ...

In some frameworks you can use a streaming API instead, but replacing a procedure call with streaming involves adding heartbeat messages, timeouts, and recovery, so many developers opt for polling instead—breaking the single request into two, like the example above.

Both approaches require changing the client and the server code, and if another method needs breaking up you have to change all of the code again. REST offers a different approach.

We return a response that describes how to fetch another request, much like a HTTP redirect. You’d handle them In a client library much like an HTTP client handles redirects does, too.

def long_running_call(self, args: str) -> Result[bool]:
    key = third_party.start_process(args)
    return Future("MyService.wait_for_long_running_call", {"key":key})

def wait_for_long_running_call(self, key: str) -> Result[bool]:
    if not third_party.wait(key):
        return third_party.is_success(key)
    else:
        return Future("MyService.wait_for_long_running_call", {"key":key})

def fetch(request):
   response = make_api_call(request)
   while response.kind == 'Future':
       request = make_next_request(response.method_name, response.args)
       response = make_api_call(request)

For the more operations minded, imagine I call time.sleep() inside the client, and maybe imagine the Future response has a duration inside. The neat trick is that you can change the amount the client sleeps by changing the value returned by the server.

The real point is that by allowing a response to describe the next request in sequence, we’ve skipped over the problems of the other two approaches—we only need to implement the code once in the client.

When a different method needs breaking up, you can return a Future and get on with your life. In some ways it’s as if you’re returning a callback to the client, something the client knows how to run to produce a request. With Future objects, it’s more like returning values for a template.

This approach works for breaking up a large response into smaller ones too, like iterating through a long list of results. Pagination often looks something like this in an RPC system:

cursor = rpc.open_cursor()
output = []
while cursor:
    output.append(cursor.values)
    cursor = rpc.move_cursor(cursor.id)

Or something like this:

start = 0
output = []
while True:
    out = rpc.get_values(start, batch=30)
    output.append(out)
    start += len(out)
    if len(out) < 30:
        break

The first pagination example stores state on the server, and gives the client an Id to use in subsequent requests. The second pagination example stores state on the client, and constructs the correct request to make from the state. There’s advantages and disadvantages—it’s better to store the state on the client (so that the server does less work), but it involves manually threading state and a much harder API to use.

Like before, REST offers a third approach. Instead, the server can return a Cursor response (much like a Future) with a set of values and a request message to send (for the next chunk).

class ValueService(Service):
    @rpc()
    def get_values(self):
        return Cursor("ValueService.get_cursor", {"start":0, "batch":30}, [])

    @rpc
    def get_cursor(start, batch):
        ...
        return Cursor("ValueService.get_cursor", {"start":start, "batch":batch}, values)

The client can handle a Cursor response, building up a list:

cursor = rpc.get_values()
output = []
while cursor:
    output.append(cursor.values)
    cursor = cursor.move_next()

It’s somewhere between the two earlier examples of pagination—instead of managing the state on the server and sending back an identifier, or managing the state on the client and carefully constructing requests—the state is sent back and forth between them.

As a result, the server can change details between requests! If a Server wants to, it can return a Cursor with a smaller set of values, and the client will just make more requests to get all of them, but without having to track the state of every Cursor open on the service.

This idea of linking messages together isn’t just limited to long polling or pagination—if you can describe services at runtime, why can’t you return ones with some of the arguments filled in—a Service can contain state to pass into methods, too.

To demonstrate how, and why you might do this, imagine some worker that connects to a service, processes work, and uploads the results. The first attempt at server code might look like this:

class WorkerApi(Service):
    def register_worker(self, name: str) -> str
        ...
   def lock_queue(self, worker_id:str, queue_name: str) -> str:
        ...
   def take_from_queue(self, worker_id: str, queue_name, queue_lock: str):
       ...
   def upload_result(self, worker_id, queue_name, queue_lock, next, result):
       ...
   def unlock_queue(self, worker_id, queue_name, queue_lock):
       ...
   def exit_worker(self, worker_id):
       ...

Unfortunately, the client code looks much nastier:

worker_id = rpc.register_worker(my_name)
lock = rpc.lock_queue(worker_id, queue_name)
while True:
    next = rpc.take_from_queue(worker_id, queue_name, lock)
    if next:
        result = process(next)
        rpc.upload_result(worker_id, queue_name, lock, next, result)
    else:
        break
rpc.unlock_queue(worker_id, queue_name, lock)
rpc.exit_worker(worker_id)

Each method requires a handful of parameters, relating to the current session open with the service. They aren’t strictly necessary—they do make debugging a system far easier—but problem of having to chain together requests might be a little familiar.

What we’d rather do is use some API where the state between requests is handled for us. The traditional way to achieve this is to build these wrappers by hand, creating special code on the client to assemble the responses.

With REST, we can define a Service that has methods like before, but also contains a little bit of state, and return it from other method calls:

class WorkerApi(Service):
    def register(self, worker_id):
        return Lease(worker_id)

class Lease(Service):
    worker_id: str

    @rpc()
     def lock_queue(self, name):
        ...
        return Queue(self.worker_id, name, lock)

    @rpc()
    def expire(self):
        ...

class Queue(Service):
    name: str
    lock: str
    worker_id: str

    @rpc()
     def get_task(self):
        return Task(.., name, lock, worker_id)

    @rpc()
    def unlock(self):
        ...

class Task(Service)
    task_id: str
    worker_id: str

    @rpc()
     def upload(self, out):
        mark_done(self.task_id, self.actions, out)

Instead of one service, we now have four. Instead of returning identifiers to pass back in, we return a Service with those values filled in for us. As a result, the client code looks a lot nicer—you can even add new parameters in behind the scenes.

lease = rpc.register_worker(my_name)

queue = lease.lock_queue(queue_name)

while True:
    next = queue.take_next() 
    if next:
        next.upload_result(process(next))
    else:
        break
queue.unlock()
lease.expire()

Although the Future looked like a callback, returning a Service feels like returning an object. This is the power of self description—unlike reflection where you can specify in advance every request that can be made—each response has the opportunity to define a new parameterised request.

It’s this navigation through several linked responses that distinguishes a regular command line tool from one that browses—and where REST gets its name: the passing back and forth of requests from server to client is where the ‘state-transfer’ part of REST comes from, and using a common Result or Cursor object is where the 'representational’ comes from.

Although a RESTful system is more than just these combined—along with a reusable browser, you have reusable proxies too.

In the same way that messages describe things to the client, they describe things to any middleware between client and server: using GET, POST, and distinct URLs is what allows caches to work across services, and using a stateless protocol (HTTP) is what allows a proxy or load balancer to work so effortlessly.

The trick with REST is that despite HTTP being stateless, and despite HTTP being simple, you can build complex, stateful services by threading the state invisibly between smaller messages—transferring a representation of state back and forth between client and server.

Although the point of REST is to build a browser, the point is to use self-description and state-transfer to allow heavy amounts of interoperation—not just a reusable client, but reusable proxies, caches, or load balancers.

Going back to the constraints (Client-Server, Stateless, Caching, Uniform Interface, Layering and Code-on-Demand), you might be able to see how they things fit together to achieve these goals.

The first, Client-Server, feels a little obvious, but sets the background. A server waits for requests from a client, and issues responses.

The second, Stateless, is a little more confusing. If a HTTP proxy had to keep track of how requests link together, it would involve a lot more memory and processing. The point of the stateless constraint is that to a proxy, each request stands alone. The point is also that any stateful interactions should be handled by linking messages together.

Caching is the third constraint: labelling if a response can be cached (HTTP uses headers on the response), or if a request can be resent (using GET or POST). The fourth constraint, Uniform Interface, is the most difficult, so we’ll cover it last. Layering is the fifth, and it roughly means “you can proxy it”.

Code-on-demand is the final, optional, and most overlooked constraint, but it covers the use of Cursors, Futures, or parameterised Services—the idea that despite using a simple means to describe services or responses, the responses can define new requests to send. Code-on-demand takes that further, and imagines passing back code, rather than templates and values to assemble.

With the other constraints handled, it’s time for uniform interface. Like stateless, this constraint is more about HTTP than it is about the system atop, and frequently misapplied. This is the reason why people keep making database APIs and calling them RESTful, but the constraint has nothing to do with CRUD.

The constraint is broken down into four ideas, and we’ll take them one by one: self-descriptive messages, identification of resources, manipulation of resources through representations, hypermedia as the engine of application state.

Self-Description is at the heart of REST, and this sub-constraint fills in the gaps between the Layering, Caching, and Stateless constraints. Sort-of. It covers using 'GET’ and 'POST’ to indicate to a proxy how to handle things, and covers how responses indicate if they can be cached, too. It also means using a content-type header.

The next sub-constraint, identification, means using different URLs for different services. In the RPC examples above, it means having a common, standard way to address a service or method, as well as one with parameters.

This ties into the next sub-constraint, which is about using standard representations across services—this doesn’t mean using special formats for every API request, but using the same underlying language to describe every response. In other words, the web works because everyone uses HTML.

Uniformity so far isn’t too difficult: Use HTTP (self-description), URLs (identification) and HTML (manipulation through representations), but it’s the last sub-constraint thats causes most of the headaches. Hypermedia as the engine of application state.

This is a fancy way of talking about how large or long requests can be broken up into interlinked messages, or how a number of smaller requests can be threaded together, passing the state from one to the next. Hypermedia referrs to using Cursor, Future, or Service objects, application state is the details passed around as hidden arguments, and being the 'engine’ means using it to tie the whole system together.

Together they form the basis of the Representational State-Transfer Style. More than half of these constraints can be satisfied by just using HTTP, and the other half only really help when you’re implementing a browser, but there are still a few more tricks that you can do with REST.

Although a RESTful system doesn’t have to offer a database like interface, it can.

Along with Service or Cursor, you could imagine Model or Rows objects to return, but you should expect a little more from a RESTful system than just create, read, update and delete. With REST, you can do things like inlining: along with returning a request to make, a server can embed the result inside. A client can skip the network call and work directly on the inlined response. A server can even make this choice at runtime, opting to embed if the message is small enough.

Finally, with a RESTful system, you should be able to offer things in different encodings, depending on what the client asks for—even HTML. In other words, if your framework can do all of these things for you, offering a web interface isn’t too much of a stretch. If you can build a reusable command line tool, generating a web interface isn’t too difficult, and at least this time you don’t have to implement a browser from scratch.

If you now find yourself understanding REST, I’m sorry. You’re now cursed. Like a cross been the greek myths of Cassandra and Prometheus, you will be forced to explain the ideas over and over again to no avail. The terminology has been utterly destroyed to the point it has less meaning than 'Agile’.

Even so, the underlying ideas of interoperability, self-description, and interlinked requests are surprisingly useful—you can break up large or slow responses, you can to browse or even parameterise services, and you can do it in a way that lets you re-use tools across services too.

Ideally someone else will have done it for you, and like with a web browser, you don’t really care how RESTful it is, but how useful it is. Your framework should handle almost all of this for you, and you shouldn’t have to care about the details.

If anything, REST is about exposing just enough detail—Proxies and load-balancers only care about the URL and GET or POST. The underlying client libraries only have to handle something like HTML, rather than unique and special formats for every service.

REST is fundamentally about letting people use a service without having to know all the details ahead of time, which might be how we got into this mess in the first place.

Apple Canada has over 30 job postings on its website ranging from Genius Bars roles to developer positions.

However, a few notable postings are aimed at recruiting people to work on video projects for Apple Canada. While some of these roles pertain to iTunes and Apple TV, a number of positions relate to video as a service.

On December 20th, 2019 the company posted job openings for a marketing manager for video, a programming manager for video and a video business manager.

The video programming manager position specifically mentions that Apple is looking for someone who “loves Movies and TV shows” and can “lead video content programming in Canada.”

The video business manager position explicitly states that Apple is looking for a “talented, innovation-driven team member to further expand our Video business in Canada.”

These jobs are interesting, since rumours about a possible Apple streaming service keep swirling.

These job postings also suggest there’s a chance that Apple has plans to bring its rumoured streaming service to Canada.

Apple has been notoriously tight-lipped regarding its streaming service. Most of the publicly available information is derived from rumours, as well as reports suggesting that the company is working with many of Hollywood’s biggest stars on television and film projects.

Apple CEO Tim Cook also told CNBC in a January 8th, 2019 interview that the company has new services that are launching this year, fueling speculation that Apple might be readying a streaming service.

This theory has been reinforced by Apple allowing television manufacturers to integrate AirPlay, HomeKit and iTunes into their products at this year’s CES in Las Vegas.

Source: Apple Canada, CNBC

The post Apple Canada posts video project jobs, raises streaming service speculation appeared first on MobileSyrup.

This month marks the 30th anniversary of the first issue of IslandSide, the venerable magazine founded by Jim Brown in 1989.

Here’s the Editor’s Note from that issue:

This is the first issue of IslandSide Magazine and I hope that, no matter where your interests lie; in politics, sports, the arts, history, fashion; you’ll find something here worth reading.

This month’s cover story is an interview I had with Joe Ghiz in December. I wanted to interview the premier to get his response to the post-election conventional wisdom that’s been swirling around the Island that, a) he is largely responsible for the Liberal sweep of seats, and b) he is gearing up for a provincial election so that, with another victory under his belt, he can turn his sights on Ottawa.

Not unexpectedly, the premier wasn’t giving anything away during our talk, but I think you’ll find his answers interesting and, although Mr. Ghiz didn’t come out and say so, I’d say a spring provincial election looks like a pretty good bet. I say that for two reasons, his vagueness when asked about calling a by-election to replace Prowse Chappell, and his apparent decision to retain the agriculture portfolio.

Barbara MacAndrew‘s story on land speculation was written before Community and Cultural Affairs Minister Gilbert Clements announced his freeze on land development pending the findings of the Royal Commission on Land Use. While his announcement addresses, at least temporarily, some of the concerns raised by Ms MacAndrew, her story provides a detailed illustration of the facts that led to the minister’s unprecedented move.

This first issue introduces readers to IslandSide’s three regular columnists. Two of them, Deirdre Kessler and Jack McAndrew, are well known to most Islanders. The third, Campbell Morrison, will be writing every month on the actions of our Island MP‘s and senators from his vantage point in the press gallery on Parliament Hill. Mr Morrison operates a news service for Maritime daily and weekly newspapers called NewsEast.

One regular feature of IslandSide that doesn’t appear in this issue. because it is the first, is the letters to the editor section. We welcome all letters and look forward to some lively debate.

I’d like to close this first Editor’s note by thanking all of the writers, photographers, artists and advertisers who took a chance, sight unseen, on IslandSide Magazine. I’d. also like to thank Jim MacNeill of the Eastern Graphic for his guidance and assistance.

IslandSide ceased publication about 6 months before I landed on Prince Edward Island and thus has long served as a helpful introduction to the cast of characters that have populated my quarter century here (I will never forget the time that—by that time Lieutenant Governor—Hon. Gilbert Clements called me looking for technical support for his Internet connection; what strange planet had I landed on).

The highlight of Issue 1 for me was Jack MacAndrew’s back page column on George Proud’s defeat of Tom McMillan, Bouquets for Ordinary George, which ended like this:

Ordinary George won one for the ordinary people. The little man you’d never notice in a crowd, stepped out of the pack and let his ordinariness win it for him. He was simply himself, without pretence, and that turned his ordinariness from a putdown to a positive. That’s the fact of the matter, whatever they may think in the drawing rooms of Brighton.

Something else. Ordinary George will do just tine at those cocktail parties on embassy row. Decency, straightforwardness, and personal humility are attractive attributes in any language. I can hear him now, telling the regulars at Tim Horton’s all about those splendid affairs.

How I wish we had someone with Jack’s insight and skill with words to interpret the times we’re living through now.

Jim Brown, of course, went on to become a national broadcasting treasure, most recently at The 180; a tip of the hat to him on this anniversary.

Thanks to my friend G. for leaving a copy of Volume 1, Number 1 on my doorstep this afternoon.

Holy cats! I just walked two blocks and back. It was a little sooner than I should have; I meant to build up to doing that over the next week or two. Going that far was exciting, though I am limping very very slowly.

I will now slather myself with Voltaren and strap ice packs onto my ankles, which are freaking out. Tiny muscles are twitching all over my legs.

Tomorrow afternoon my plan is to go to the warm pool to walk around some more.

Change is hard, and often controversial. Especially in the realm of web technology, the pace of change makes everyone occasionally feel overwhelmed, like they’re slipping behind. It’s tempting to assume a conservative or reactionary position, assuming that new complexity is ‘for its own sake’.

But I’m optimistic about the evolution of the web, and am watching a lot of early-stage changes with anticipation. Here are some of them.

The pipeline operator

The pipeline operator is cool because it could create peace between functional programming and fluent interfaces. Take date libraries for example. There’s the hugely-popular moment, which has an interface like

moment().startOf('day').fromNow();

And then there’s the newer, hipper date-fns, which would express the same as

formatDistance(startOfDay(new Date()));

moment’s interface will feel familiar to folks who’ve used jQuery or d3 in the past - you call methods on an object and it keeps returning this (itself) so you can keep chaining those method calls.

In my opinion, this is a classic situation where sometimes you want to write code one way, and other times it works better the other. With current libraries, that’s just not possible – you write a library to work with the fluent style or with the functional style.

The pipeline operator could fix all of this: you could write modules in the functional style and then call them fluently. For example, if the pipeline operator landed, then you could write this with date-fns:

new Date() |> startOfDay |> formatDistance

And they could this without changing date-fns at all.

The pipeline operator will be familiar to folks who have used Elm or Clojure. When I’ve worked in those languages, it has really shined, and I’d love for this API design question to be finally answered in a way that makes it easier for package maintainers to make everyone happy.

Class properties and ES Modules

If you’ve been writing modern JavaScript, there’s a good chance you’ve already started using these things. Many React projects use class properties to keep the value of this correct when a React.Component method is called from an event handler. And lots of projects web-wide use ES Modules through tools like Webpack and Rollup, which bundle together a project-wide set of modules into one production file.

But today you need to use something like Babel to transpile class properties so that they work in shipping browsers, and you need a tool like Rollup, Webpack, or Parcel to transform ES Modules into a bundle.

The day when you don’t need these tools is soon approaching, and it’s pretty exciting. Imagine a development process that didn’t rely on bundlers. And then when it comes time to deploy, you don’t have to rely as heavily on sourcemaps to debug errors, because the deployed code is so similar to the source.

Then, once dynamic import() lands in enough browsers, code splitting can rely on a standardized and simple technique, rather than the kludge of a module-loader that webpack hardcodes into bundles today.

The read/write files API

This is the most controversial of the bunch: it’s a proposal that would add a new API allowing browsers to request access to read & write files on people’s computers. It’s rightfully a discussion, because a naïve implementation could be a security trap and allow web applications to, perhaps, read arbitrary files. But the writers are well-aware of the risks and are being very thoughtful in the design.

This feature would be a boon to nearly every project I’ve worked on - for example, iD could more easily work with XML and JSON files to enable offline editing of OpenStreetMap. Observable could save and open notebooks locally. Mapbox Studio could interoperate better with people’s local SVG files.

Perhaps at some point in the web’s evolution, the concept of local files on disk could’ve gone away, but that didn’t happen. People still use local files, even if they’re on a Chromebook, and the inability of web apps to easily read & write those files is one reason why people continue to use Electron and other web-on-desktop technologies that bring their own complexities and downsides - like, for example, separate WebKit/Chrome instances per app.

BigInt

let biggerThanEverBefore = 90071992547409926700n;

I’ve been using this one already: BigInt is a proposal to add arbitary-precision integers to JavaScript.

There are many rants about numbers in JavaScript, a fair number of which accidentally apply to every language that uses IEEE floating point numbers. But one of those critiques that does sting is that JavaScript only has 53 bits of precision for integers, because all numbers are stored as floating point.

This doesn’t often crop up as a real problem, but when it does the workarounds are pretty brutal – libraries like big.js are available but rob you of all built-in syntax (you can’t use +, -, /, and other operators), and always incur some performance hit. Personally, I run into integer precision issues when trying to solve Project Euler questions, but there are less pedantic cases. For example, indexing systems like Google S2 rely on 64-bit integers as their basic abstraction, and parsing a variety of files into JavaScript yield integer overflows. CSVs, for example, set no limit on the maximum size of a number.

The BigInt proposal adds 64 bit integers and beyond - you deal with arbitrarily large integers, as long as you declare them with a particular syntax, which requires you to append n at the end of each number.

These are all proposals. Web standards can succeed for fail at nearly any time, and some of these are very early. Read/write files, for example, is at a very early stage. It might not happen. Same with the pipeline operator. BigInt will probably get implemented everywhere, because it’s already shipped in Chrome, but it might change a little before Firefox supports it. Class properties are getting there, and same with ES Modules. ES Modules have trod the rockiest road of all, with plenty of surprise changes.

Next Tuesday, I’m hosting a free webinar to break down the community strategy process.

You’re going to learn what a strategic plan looks like, the key components of the plan, how to undertake good research, and why some plans are used while others are ignored.

You can sign up using the link below.

https://attendee.gotowebinar.com/register/5307593711920282882

If you’re looking to evaluate your own strategy or be inspired to rebuild your strategy, this webinar will probably help (and if it doesn’t, I promise a full refund!)

I hope to see you there.

p.s. Here are some bonus community strategy resources:

• Strategic Community Management
• Community Strategy Roadmap Templates
• CMX Talk – The Indispensable Community

Ich verstehe jetzt die Kennzeichnung der Lenovo-Rechner:

C = Convertible
S = UltraSlim
D = Detachable
L = Laptop
Y = Gaming

Das hier ist ein S940, also Ultraslim. Ursprünglich hat Lenovo die Marke Yoga nur für Convertibles verwendet, nun bezeichnen sie auch normale Laptop-Designs so. Bei den ThinkPads steht Yoga dagegen immer noch für Convertible.

Die letzten beiden Ziffern bezeichnen natürlich die Generation. Yoga 900, 910, 920, C930, jetzt S940. Neben dem schlanken Design hat dieses neue Geräte eine Menge Funktionen, über deren Nützlichkeit ich mir noch nicht im Klaren bin. Hübsch ist es. Trotzdem passt das C930 besser zu meinen Ansprüchen.

A sex toy called Osé from the company Lora DiCarlo won an award at the Consumer Electronics Show. Then the show’s organizer, the Consumer Technology Association, took the award away. Lora DiCarlo founder Lora Haddock’s pointed, honest response is one of my favorite press releases of all time. Obligatory content warning: If it bothers you … Continued

The post Lora DiCarlo’s CES sex toy press release made me ecstatic appeared first on without bullshit.

For years I held the domains makerhouseholds.com and .net, next to the .eu one. Recently I decided to let the .com and .net one go.

Cue the domain sellers in my inbox. EasyRegisters spammed me today. You have a similar domain! And this one is now available! Pay only $90!
Yes, available because I let it go.

I know this type of thing exists, but it really is an irksome valueless “service” and a form of rent seeking.

Marked as spam.

The January winter is always a time where people evaluate effectiveness and success, and looking at New York City’s High Line is no different. This article by Justin Davidson in the New York Magazine describes the author’s ennui with the place, as it transformed from an old 30 foot high 1.45 mile (2.33 km)  long train bridge to a wildly successful people place.

Davidson minces no words describing the High Line as “an elevated cattle chute for tourists, who shuffle from the Whitney to Hudson Yards, squeezed between high glass walls and luxury guard towers. The views are mostly gone, which is a good thing because stopping to admire one would cause a 16-pedestrian pileup. The rail-level traffic mirrors the congestion overhead, caused by construction so hellbent on milking New York’s waning real estate hyper-boom that any patch of land bigger than a tick’s front yard is considered suitable for luxury condos.”

I spent time with Mitchell Silver, New York City’s Park Commissioner and Robert Hammond, one of the founders of the High Line walking the length of the project, and described that here. Mitchell observed that locals stay away from the High Line during “tourist season” hours, and also stressed that the width of the walkway~fifteen feet~was inadequately narrow, despite best intentions. The reuse of an  old highway overpass in Seoul Korea has resulted in the creation of Seoullo 7017, a fantastic arboretum and linear park thirty feet in the air. When I visited this project last year, designers also said that their walkway~which was also fifteen feet wide~was too narrow as well. This project is well-lit and open 24 hours a day and has a bakery and a daycare on its deck.

Seoullo7017

While it is popular to believe that the High Line has been responsible for the rejuvenation and revitalization of this very old meatpacking district, I beg to differ.

The Port Authority Building at 111 Eighth Avenue  is adjacent to the High Line, and was until the 1960’s the largest building in New York City.

After leasing this building the Google Corporation purchased the fifteen story monolith in 2010. It contains 2.9 million square feet (think of it as two Tsawwassen Mills Malls) in its massive interior. Having Google employees and the associated businesses in the area would have been an incubator putting pressure on the adjacent businesses which included nightclubs and former buildings associated with the meatpacking industry. While still containing some of the earliest buildings associated with the Dutch settlement of New York City, this area was one of the last available with large lot size and cheaper real estate prices.

Much like Vancouver’s Seaside Greenway, the residential development along the High Line may not be affordable, but that does not change the fact that the High Line is accessible to the public. The public park is also managed by a non-profit conservancy working with NYC’s Department of Parks and Recreation. While the conservancy manages the maintenance, operation and public programming for the park, they are also able to accept donations and will bequests for the park. This is a concept that is still relatively new, leaving money for the on-going management of public space.

In his article on the High Line  Davidson observes that the area “has become a social club for celebrity architects, who compete by pretending that their fellow members simply don’t exist…Bjarke Ingels Group is erecting an even BIGger pair of towers, twisting and leaning towards each other above a whole city block. …”

In summation,  Davidson could have been addressing downtown Vancouver~”The rap on luxury development in New York is that it’s geared to absentee owners, who barely stop in for a shower on a layover between continents. But that may change. The Treasury Department has tightened rules for high-end, all-cash real estate purchases, aimed at preventing buyers from hiding their identities behind shell companies. Shady gajillionaires now have to slink off and launder their embezzled fortunes somewhere else, which could land some imperial apartments on the bargain table.”

If indeed foreign investment does fall off in New York City, the citizens are still left with this extraordinary gem of  a public park. Built on an old rail overpass the High Line has turned into a much-loved amenity with  public art, theatre performance, gardens, and benches. It is a place people congregate to and spend time in.
Instead of thinking of crowds and congestion as being the High Line’s destruction, this park’s popularity has led the way in creatively rethinking urban infrastructure, and we are all the better for that.

End of the Year Report – Librem 5 – Things are awesome

Hello everyone! We have accomplished so much in the last 3 months and need to share, so prepare yourself for a dense update on the Librem 5 phone, PureOS, and software applications.

As you know, we have a number of important components in the Librem 5 that we will try outline.

Calls

Let’s start off with the Calls application.  The calls application is what allows us to place phone calls and what makes the phone a
phone.  In these past few months, we’ve been making this application work wonderfully.  Below is a demo of the calls application receiving a phone call.  So the basic support for the calls application is complete and we’re working making a great design.  We’ve successfully implemented important basic features like ring tones.

If you’re interested in following the work, we’ve included the merge
requests for calls below and important issues that were created:

Merge Requests

https://source.puri.sm/Librem5/calls/merge_requests/5 – flatpak: enable access to dconf config
https://source.puri.sm/Librem5/calls/merge_requests/20 – new-call: set input hints and purpose of SearchEntry
https://source.puri.sm/Librem5/calls/merge_requests/25 – mm-provider: clarify warning a bit
https://source.puri.sm/Librem5/calls/merge_requests/23 – history-box: add empty view
https://source.puri.sm/Librem5/calls/merge_requests/19 – add i18n support
https://source.puri.sm/Librem5/calls/merge_requests/4 – add test for origin and calls
https://source.puri.sm/Librem5/calls/merge_requests/21 – add calls-application class
https://source.puri.sm/Librem5/calls/merge_requests/18 – add a call window and header bars
https://source.puri.sm/Librem5/calls/merge_requests/26 – display dialer on startup
https://source.puri.sm/Librem5/calls/merge_requests/28 – post ui change cleanups
https://source.puri.sm/Librem5/calls/merge_requests/18 – add call window and header bars
https://source.puri.sm/Librem5/calls/merge_requests/27 – flatpak support
https://source.puri.sm/Librem5/calls/merge_requests/29 – fixed memory leak
https://source.puri.sm/Librem5/calls/merge_requests/32 – pay attention to the addition and removal of a modem
https://source.puri.sm/Librem5/calls/merge_requests/33 – flatpak: Don’t build the libhandy Glade catalog
https://source.puri.sm/Librem5/calls/merge_requests/34 – cleaned up ringtone ringer
https://source.puri.sm/Librem5/calls/merge_requests/35 – providers in calls are now plugins
https://source.puri.sm/Librem5/calls/merge_requests/36 – updated calls icons
https://source.puri.sm/Librem5/calls/merge_requests/37 – flatpak building
https://source.puri.sm/Librem5/calls/merge_requests/38 – changes to support impending call history changes

Issue Requests

https://source.puri.sm/Librem5/calls/issues/18 – memory leak in find_call_holder
https://source.puri.sm/Librem5/calls/issues/19 – memory leak in set_focus
https://source.puri.sm/Librem5/calls/issues/20 – memory leak in calls_call_window_add_call
https://source.puri.sm/Librem5/calls/issues/36 – transferred TODO list to gitlab issues
https://source.puri.sm/Librem5/calls/issues/7#note_11069 – investigation into evolution data server/sqlite
https://source.puri.sm/Librem5/calls/issues/22 – DTMF fails with error Rejected send message

Hægtesse

Hægtesse is a daemon to transfer audio data between a modem and PulseAudio.  It currently only supports the SIMCom SIM7100 modem but may be useful for other modems.  The purpose of Hægtesse is to monitor the modem and when a call is initial to configure PulseAudio automatically for a phone call.  This is a necessary component for phone calls.

Issues

https://source.puri.sm/Librem5/haegtesse/issues/1 – fills log when /dev/tty4 is not present

Merge Requests

https://source.puri.sm/Librem5/haegtesse/merge_requests/3 – Hægtesse listen to udev for the appearance of the audio TTY
https://source.puri.sm/Librem5/haegtesse/merge_requests/4 – Add full GPLv3 text
https://source.puri.sm/Librem5/haegtesse/merge_requests/5 – Build with gitlab-ci
https://source.puri.sm/Librem5/haegtesse/merge_requests/7 – fix build on PureOS

Libhandy

Libhandy is a library that extends GTK+ to be used on mobile profiles.  With libhandy, you can port any GTK3 or higher app that you have into a mobile profile.  If you have an application written in GTK3, reach out and we’d be happy to help you port it to libhandy.  To find out more about libhandy go here:
https://source.puri.sm/Librem5/libhandy/wikis/home for our roadmap.

Here is an example of GNOME Web (epiphany) ported libhandy

Documentation and example code.

Libhandy has had made significant advancements these months with several releases made.

Libhandy is currently being used to port many core GNOME apps to the librem5

Merge requests:

https://source.puri.sm/Librem5/libhandy/merge_requests/137 – HdyDialer: Apply ‘keypad’ style class
https://source.puri.sm/Librem5/libhandy/merge_requests/145 – Don’t invoke signal handlers on finalized HeaderGroups
https://source.puri.sm/Librem5/libhandy/merge_requests/147 – add i18n support
https://source.puri.sm/Librem5/libhandy/merge_requests/146 – doc fix
https://source.puri.sm/Librem5/libhandy/merge_requests/145 – HdyHeaderGroup signal disconnections
https://source.puri.sm/Librem5/libhandy/merge_requests/146 – few documentation fixes
https://source.puri.sm/Librem5/libhandy/merge_requests/147 – enabling l10n
https://source.puri.sm/Librem5/libhandy/merge_requests/148 – g_auto* documentation
https://source.puri.sm/Librem5/libhandy/merge_requests/150 – drop Jenkinsfile
https://source.puri.sm/Librem5/libhandy/merge_requests/151 – Syntax highlight HACKING
https://source.puri.sm/Librem5/libhandy/merge_requests/152 – Init public GObject types in hdy_init()
https://source.puri.sm/Librem5/libhandy/merge_requests/153 – fixes to MacOS Build
https://source.puri.sm/Librem5/libhandy/merge_requests/154 – Add measure() methods
https://source.puri.sm/Librem5/libhandy/merge_requests/155 – drop direct access to event fields
https://source.puri.sm/Librem5/libhandy/merge_requests/156 – renaming margins for GTK4 support
https://source.puri.sm/Librem5/libhandy/merge_requests/157 – make HdyDialer a descendant of GtkBin
https://source.puri.sm/Librem5/libhandy/merge_requests/159 – fix a mention of a HdyLeaflet in the docs
https://source.puri.sm/Librem5/libhandy/merge_requests/162 – unstability acknowledgement documentation improvements
https://source.puri.sm/Librem5/libhandy/merge_requests/165 – normalize and document private header guards
https://source.puri.sm/Librem5/libhandy/merge_requests/166 – adding hdysearchbar
https://source.puri.sm/Librem5/libhandy/merge_requests/167 – remove useless libhandy options from example flatpak
https://source.puri.sm/Librem5/libhandy/merge_requests/168 – document more coding style
https://source.puri.sm/Librem5/libhandy/merge_requests/169 – reproducible build of libhandy
https://source.puri.sm/Librem5/libhandy/merge_requests/172 – hdy_init() docs improvements
https://source.puri.sm/Librem5/libhandy/merge_requests/173 – add transfer none to hdy_init()
https://source.puri.sm/Librem5/libhandy/merge_requests/174 –  fix HdyHeaderGroup references
https://source.puri.sm/Librem5/libhandy/merge_requests/175 – example: put the content in a scrolled window
https://source.puri.sm/Librem5/libhandy/merge_requests/176 – add many row widgets
https://source.puri.sm/Librem5/libhandy/merge_requests/177 – leaflet: clear the children list on disposal
https://source.puri.sm/Librem5/libhandy/merge_requests/178 – build: set the shared object install directory
https://source.puri.sm/Librem5/libhandy/merge_requests/179 – update meson.build for MinGW compatibility
https://source.puri.sm/Librem5/libhandy/merge_requests/180 – build: dont’ use -fstack-protector-strong on mingw64
https://source.puri.sm/Librem5/libhandy/merge_requests/181 – update docs skeleton

Issues:
https://source.puri.sm/Librem5/libhandy/issues/57 – HdyTitleBar broken with .devel window in org.gnome.Sdk//master
https://source.puri.sm/Librem5/libhandy/issues/52 – issues compiling on OSX

Librem5-devkit-tools

Librem5 devkit tools are the set of tools to enable the devkit that was recently shipped out to crowdfunding supporters.

– https://source.puri.sm/Librem5/librem5-devkit-tools

Virtboard

Virtboard is our virtual keyboard used on the Librem 5.  Work has been on-going in enabling the virtual keyboard mostly focusing on making this input working under wayland.  The UX experience is still on-going.  Feedback is of course encouraged.

Merge requests
– https://source.puri.sm/Librem5/virtboard/merge_requests/20 Unbreak virtboard crashing when using GCCs stack protector
– https://source.puri.sm/Librem5/virtboard/merge_requests/21 Update input-method protocol
– https://source.puri.sm/Librem5/virtboard/merge_requests/22 make virtboard fully hidden
– https://source.puri.sm/Librem5/virtboard/merge_requests/23 virtboard translations
– https://source.puri.sm/Librem5/virtboard/merge_requests/24 convert to glib mainloop
– https://source.puri.sm/Librem5/virtboard/merge_requests/25 added multiple layouts

Chatty

Chatty is our combination SMS and encrypted communication app.  Chatty currently works with SMS and with the help of libpurple we can also have E2E encrypted communication as promised before.

We currently can successfully send SMS between phones.  Below is a demo of the chatty doing some emoticons.  You might recall last post we showed chatty doing real SMS.  The UX experience is still on-going and continues to evolve.  Follow along in this issue –

https://source.puri.sm/Librem5/chatty/issues/52 for how the UX is coming along.

Merge requests

– https://source.puri.sm/Librem5/chatty/merge_requests/1 Add some basic gitlab-ci
– https://source.puri.sm/Librem5/chatty/merge_requests/2 fixing the Flatpak manifest
– https://source.puri.sm/Librem5/chatty/merge_requests/3 porting the window to Glade
– https://source.puri.sm/Librem5/chatty/merge_requests/4 Remove arm special casing
– https://source.puri.sm/Librem5/chatty/merge_requests/5 don’t access inexistent header bar
– https://source.puri.sm/Librem5/chatty/merge_requests/6 Use glib’s logging
– https://source.puri.sm/Librem5/chatty/merge_requests/7 Don’t ignore compiler warnings
– https://source.puri.sm/Librem5/chatty/merge_requests/9 Fix build with a default set of warnings enabled
– https://source.puri.sm/Librem5/chatty/merge_requests/10 Enable and fix more compile warnings
– https://source.puri.sm/Librem5/chatty/merge_requests/13 Fix crash during message parsing
– https://source.puri.sm/Librem5/chatty/merge_requests/14 Make text in chat bubble copyable
– https://source.puri.sm/Librem5/chatty/merge_requests/15 Fix new messages not being displayed
– https://source.puri.sm/Librem5/chatty/merge_requests/16 Prepare chatty for translations
– https://source.puri.sm/Librem5/chatty/merge_requests/17 Fix time format display
– https://source.puri.sm/Librem5/purple-mm-sms/merge_requests/1 Add Debian packaging
– https://source.puri.sm/Librem5/chatty/merge_requests/21 – add Debian packaging
– https://source.puri.sm/Librem5/chatty/merge_requests/29 – don’t use network when verifying appdata files
– https://source.puri.sm/Librem5/purism-chatty/issues/5 Suggested closing the old project
– https://source.puri.sm/Librem5/chatty/issues/52 – improve chatty UI

Design

Most of our design is being done in GNOME upstream except of course for the UX experience in the Librem 5 specific component.  Purism believes deeply in working in the upstream and we work closely with GNOME’s designers.  Below are a number of design mockups that were conceived for various GNOME apps to work with libhandy.

– https://gitlab.gnome.org/Teams/Design/app-mockups/blob/master/todo/todo.png Adaptive Mockups for GNOME TODO
– https://gitlab.gnome.org/Teams/Design/app-mockups/blob/master/notes/notes.png – Adaptive Mockups for GNOME Notes
– https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/view-switcher/adaptive-view-switcher-modes.png – proposal for adaptive view switching modes (commited to implement by Adrien)
– https://gitlab.gnome.org/GNOME/Initiatives/issues/2 – new app icons for GNOME

In addition, a lot of work has gone in to designing parts of GNOME like the control center to work in a mobile context.

WLroots

WLroot is the Wayland implementation for the Librem5 and which phosh our UX shell runs on.  Mostly working on getting libinput working.  We did some investigations on using rust bindings, but turned out that it was more work with very little advantage.

Merge requests:
– https://packages.debian.org/source/experimental/wlroots – update debian packaging
– https://source.puri.sm/Librem5/wlroots/merge_requests/35 – input-method and text-input support to the Librem5
– https://source.puri.sm/Librem5/wlroots/merge_requests/40 – wlroots update

Issues:

– https://source.puri.sm/Librem5/wlroots/issues/6 – rootston freezes on ssh log out
– https://source.puri.sm/Librem5/wlroots/issues/18 – rootston often freezes

Phosh

Phosh is the actual visual look and feel of the Librem 5.  The most significant work here is being able to detect idle and dim the screen automatically when not on battery power.  Some work on the lock shield was also done and various UX fixes and features.
For more information see the merge requests before.

Merge requests

– https://source.puri.sm/Librem5/phosh/merge_requests/143 Update translations from zanata
– https://source.puri.sm/Librem5/phosh/merge_requests/153 – Drop hard coded weston-terminal from favorites
– https://source.puri.sm/Librem5/phosh/merge_requests/154 – Add a poweroff button to the settings menu
– https://source.puri.sm/Librem5/phosh/merge_requests/158 – use actual values for transform instead of looking at rotation property
– https://source.puri.sm/Librem5/phosh/merge_requests/159 – make sure setting buttons stay circular

Issues

– https://source.puri.sm/Librem5/phosh/issues/52  – look into full screen blank support on lock

Upstream Work

Purism knows it stands on the shoulders of giants.  We would not be be successful without our upstream partners.  We make sure that our technical debt is as small as possible, preferring to work in upstream as much as a matter of course.  Below is a list of the work we have done in the various upstreams that we depend on.  This is not an exhaustive list of projects since we do other upstream work for our laptops as well.

We are very proud of our upstream work and being part of these upstream projects.

– https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910640 – Debian’s libgtk-4-dev Needs to depend on libvulkan-dev
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/200 – Kept pushing making the WiFi panel adaptive
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/243 – Moving the app menu
– https://gitlab.gnome.org/GNOME/gnome-contacts/merge_requests/41 – contact deselection on creation fix
– https://gitlab.gnome.org/GNOME/gnome-contacts/merge_requests/42 – using HdyHeaderGroup
– https://gitlab.gnome.org/GNOME/gnome-contacts/merge_requests/43 – using HdyTitleBar
– https://gitlab.gnome.org/GNOME/gtk/issues/1399 – Suggested to not show dashed border in keyboard-navigable selected elements when no keyboard is available
– https://gitlab.gnome.org/GNOME/Initiatives/wikis/GNOME-apps-mobile – Helped Javier set up the initiative
– https://github.com/swaywm/wlroots/pull/1316 – don’t let the wlr_output handle the fullscreen view in case

– https://github.com/swaywm/wlroots/pull/1203 – Support input method and text input
– https://gitlab.gnome.org/GNOME/gtk/merge_requests/384  – reviewed fix for text input protocol
– https://github.com/haecker-felix/Fragments/pull/41 – fixed a text flickering
– https://gitlab.gnome.org/GNOME/gitg/merge_requests/21 – GtkActionBar for the commit tool bar
– https://gitlab.gnome.org/GNOME/gitg/merge_requests/22 – fixing the diff options sliding direction
– https://gitlab.gnome.org/GNOME/glade/issues/339 – Suggested to not destroy existing property bindings
– https://gitlab.gnome.org/GNOME/glade/issues/340 – Suggested to support property bindings
– https://github.com/swaywm/wlroots/pull/1316 – Fix bug with full screen views and overlays (otherwise it will cause trouble with full screen video/pdf vs the lock screen
– https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911146 – xwayland spurious crashes
– https://github.com/swaywm/wlr-protocols/pull/27 – securing wayland protocols
– https://gitlab.gnome.org/Community/Purism/gnome-software/tree/wip/aplazas/narrow – start of adaptive
– https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/92 – supplementary call operations
– https://gitlab.gnome.org/GNOME/gtk/issues/1447 – tried to solve input method complications in gnome-shell
– https://gitlab.gnome.org/Community/Purism/gnome-clocks/tree/librem5 – librem 5 clock application
– https://bytesgnomeschozo.blogspot.com/2018/11/gnome-at-capitole-du-libre-2018.html – blog post on Capitole du libre conference
– https://gitlab.gnome.org/GNOME/gtk/merge_requests/425 – transient window notification fix to 3.24
– https://gitlab.gnome.org/World/lollypop/merge_requests/1319 – flatpak build fix for lollypop
– https://gitlab.gnome.org/GNOME/epiphany/merge_requests/56 – make title bar more adaptive
– https://gitlab.gnome.org/GNOME/epiphany/merge_requests/59 – make search bar adaptive
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/312 – 4 adaptive panels for GNOME settings
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/313 – make shell more adaptive
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/200 – Wifi panel adaptive
– https://gitlab.gnome.org/GNOME/gnome-characters/issues/46 – icon mismatch
– https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/317 – implement new network connection editor design
– https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/59 – policy: call method name should be SendDtmf rather than SendTone
– https://gitlab.gnome.org/GNOME/libgnome-volume-control/merge_requests/3 – make debug less verbose
– https://source.puri.sm/Librem5/wlroots/merge_requests/40 – WIP: Update 0.2
– https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/43 – rework wwan plugin after upstream feedback

Documentation

This effort can never survive without documentation.  In that regard, welcome David Boddie to the Librem 5 team working on documentation for the Librem 5.  The whole team, while focusing on their development, are equally aware of the role of documentation and have worked diligently in making sure that people create applications for the Librem 5.  With two members working exclusively on documentation and developer experience, we hope to make writing applications for the Librem 5 as easy as it can be.  Feedback in improving our documentation would be most welcome!

A lot of focus was made on creating documentation on how to create Librem 5 applications with sample code.

Issues

– https://source.puri.sm/Librem5/developer.puri.sm/issues/28 – Upate GNOME Builder section

Merge requests

– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/55 – GTK+ limit the documentation to libhandy 0.0.3
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/60 – update qemu
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/61 – update email lists to be lists.community.puri.sm
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/63 – add stack picture and more intro
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/68 – GTK+: add links to the GTK+ and libhandy docs
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/71 – GTK+: Note to adjust label’s xalign when ellipsized
– https://source.puri.sm/david.boddie/python-gobject-gtk3-examples – collection of simple PyGObject examples
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/84 – document phosh’s supported DBus APIs
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/85 – document some trivial phosh apis
– https://source.puri.sm/Librem5/developer.puri.sm/merge_requests/82 – added small descriptions of KDE-related technologies

Phone hardware/Dev Kit

The recent shipping of the Librem 5 dev kit represents countless hours of work with an aggressive schedule.  Nicole, Eric, and Petra, along with dedicated operations staff, worked continuously for a week to package all the dev kits to be shipped out to our dev kit backers.

When it comes to software and hardware freedom, we not only do the talk, we do the walk.  Everything in the dev kit, is licensed under the GNU GPL v3+.  We have released the schematics for the dev kit and all source files.  We encourage you to participate and bring your talents and join us!

By now everyone who ordered a dev kit would have received it and are working on the hardware to get it fully enabled from the LCD panel to user-controlled LEDs.  We will be sharing more photos and videos of the dev kits in action as more and more community members advance the software around them.

In the meanwhile, our matrix channel has become a hot bed of activity as people prod and poke their dev kits, asking questions and following along with the devleopment of the phone.

As for the phone, we have confirmed the BOM (Bill of Materials) and the sourcing of parts, we are only finalizing the I.MX 8M or 8M Mini by benchmark testing. Once we have approved the design (also planned in January) we can create the necessary molds and stamps.

January is going to be really busy for Purism as we split time between the dev kit advancements and then pivoting to the Librem 5 phone hardware, but we welcome the excitement around what we’re doing.  We will have a retrospective post on the dev kit tomorow (2019-01-09), so stay tuned for that!

Short Summary of the work:
– Moved to Kernel 4.18.11
– Reworked device tree for dev kit
– add texture support on GC7000   https://source.puri.sm/guido.gunther/mesa/tree/gc7000-bo-relocs,   https://source.puri.sm/guido.gunther/mesa/tree/gc7000-bo-relocs
– PureOS now building on our build server using Laniakea build system
– a mechanical issue was discovered with the M.2 module not sitting flush against the board so a taller M.2 connector was used on the final dev kit design
– RedPine fixing the W_DISABLE# issue, they will use a bodge wire for our 340 dev kit units so that the HKS works as anticipated
– Fixed various issues in the nwl-dsl (mipi) driver
– picture of working HDMI – https://talk.puri.sm/_matrix/media/v1/download/talk.puri.sm/SSvCOnFIIdtgeXqmrMrjZkje
– Fixup several bugs in the imx8ms mipi dsi layer
https://source.puri.sm/Librem5/linux-emcraft/commit/2a10a1eaee8860f0f79b513497039ca21a5ded76
https://source.puri.sm/Librem5/linux-emcraft/commit/34bfd44c92bd32b4cd8c88a7943ced00c699a398
https://source.puri.sm/Librem5/linux-emcraft/commit/937cb53b89c26ba3011ea05f6ae14b1134036a6c

– Initial (WIP) LCD panel driver
https://source.puri.sm/guido.gunther/linux-imx8/commit/919a834a865824eeeeb9b98bc4932ae46a614fba
+ Look at haptic sensor. Driven by the kernel’s joystick force feedback
interface (and therefore exposed to userspace as an input
device). We’ll need write a tiny driver for that.

Purism in the Public

Purism employees are not hermits and you can find them at various conferences.  Here are some of the things our employees have done.

– Dorota: Gave a talk based on Rust+Wayland research, dutifully credited Purism (video incoming… at some point): http://rust.cologne/2018/10/10/at-cisco.html

– Adrien and Francois were at Capitole du Libre, running the GNOME booth there.

FOSDEM – A number of us will be at FOSDEM doing talks and hanging out.  More information on what our plans are for FOSDEM in another post.

Closing

That’s all for now!  Stay tuned on these pages for new applications, the retrospective on the dev kit, and other features!  Things are rolling fast!  Thank you to our fans for making 2018 a wonderful year and looking forward to 2019!  It’s going to be awesome!  Thank you for a great year!

The post End of Year Librem 5 Update appeared first on Purism.

Apple Frames, my shortcut to add device frames to screenshots taken on modern Apple devices, has been updated with support for the 11" iPad Pro and 40mm Apple Watch Series 4. This marks the second major update to Apple Frames, which now supports the following Apple devices:

• iPhone 6, 7, 8, and X
• iPhone XS and XS Max
• iPad Pro 11" and 12.9" (2018 models)
• Apple Watch Series 4 (44mm and 40mm)
• MacBook Pro (Retina 13")
• iMac 5K

For iOS devices, Apple Frames works with both landscape and portrait screenshots, but doesn't support iPhone screenshots taken with Display Zoom enabled. As I detailed in the original post, if you pick multiple screenshots when running the shortcut, their framed versions will be combined in a single image at the end.

I bought an 11" iPad Pro to use as a media/gaming device last month (I'll talk about this on Connected soon), and I was annoyed by the inability to frame its screenshots with my shortcut because, as I noted at the time, Apple's Marketing mini-site didn't provide product images for the smaller iPad Pro. As it turns out, however, I was looking in the wrong place. Apple's UI Design Resources for iOS, which can be downloaded here, do offer an official iPad Pro 11" template for designers and developers who want to test their interfaces inside a "real" device frame or who need to put together marketing assets for their apps. As with all the other device images included in Apple Frames, Silvia adapted Apple's assets to work with Shortcuts and you won't have to download or install anything. After we discovered where the 11" iPad Pro assets were located, we downloaded the watchOS UI resources and adapted the 40mm Apple Watch frame to the shortcut as well.

Framed screenshots from the Apple Watch Series 4 40mm.

At this point, I'm quite happy with the performance and flexibility of Apple Frames and I don't see any other major updates on the horizon. The only missing device is the iPhone XR, but Apple has not posted official frames for the device anywhere yet. If that changes, I'll make sure to update the shortcut accordingly.

In the meantime, you can download the latest version of Apple Frames (with an iOS-only version too) below.

Apple Frames

Add device frames to screenshots for iPhones (6, 7, 8, X, and XS generations in standard/Plus/Max sizes), iPad Pro (11" and 12.9", 2018 models), Apple Watch S4 (40 and 44mm), MacBook Pro (Retina 13-inch), and iMac (5K). The shortcut supports portrait and landscape orientations, but does not support Display Zoom. If multiple screenshots are passed as input, they will be combined in a single image.

Get the shortcut here.

Apple Frames (iOS-only)

Add device frames to screenshots for iPhones (6, 7, 8, X, and XS generations in standard/Plus/Max sizes), iPad Pro (11" and 12.9", 2018 models), and Apple Watch S4 (40 and 44mm). The shortcut supports portrait and landscape orientations, but does not support Display Zoom. If multiple screenshots are passed as input, they will be combined in a single image.

Get the shortcut here.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it's also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it's made in Italy.

I took my iPhone into the Apple Store today to get its camera fixed. Somehow, one of the elements in this telephoto lens cracked over the holidays. The service people hadn’t seen anything quite like it, and I’m sure they’ve seen their share of weird stuff. Since there was no external damage and all the diagnostics checked out, however, Apple is fixing it under warranty.

Funny thing: on the way home, I almost got a ticket from a fare inspector on the train. I’d hadn’t thought it through that my monthly fare card was on my phone, which wasn’t with me. Oops. Luckily, the inspector accepted my excuse and let me off with a warning. Whew.

Back in 2013, I just started using a Safe Zone helmet mirror, and I figured it was high time for an update: this mirror is by far the best on the market. As you might be able to tell from pretty much any of the self portraits of me on a bike over the past few years, this is the only mirror I use now. I have one on both of the helmets that I regularly use.

The mirror itself is nice and big, but what makes the whole thing special is the fact that you can reposition the mirror on the fly and it will stay in position.

The one issue that I can see with the mirror is that it is not easily available in Canada. However, if you are lucky enough to live in Toronto, then Matteo of Matteo’s Mobile Bike Repair will be more than glad to sell you one for considerably less that what you would pay on Amazon, or by ordering directly from the company (especially after shipping and currency conversion). You’ll save even more if you meet up with him to pick it up in person.

He said that he is not really interested in making money reselling something that keeps people safe.

Thanks Matteo!

Update:

note that I was using velcro to attach the mirror mount so that I could switch the mirror between two different helmets. However, the disadvantage was that the velcro would allow the mirror to wobble a bit. Since I now have two mirrors, I’ve used double sided gorilla tape to mount the mirror onto the white helmet. Normal helmets have enough vents so that you can use zipties to mount the mirror, but the white helmet (a Torch T2, BTW) does not.

There are 23,620 electric vehicles (EV) and 5,841 charging stations across Canada, according to a new report compiled by British financial services firm Go Compare.

Go Compare collected data for 30 countries that are part of the International Energy Agency (IEA). The data comes from The European Alternative Fuels Observatory an Global EV Outlook. All of the information is accurate up to the end of 2017, according to Go Compare.

While Canada’s EV market is growing, it still has a long way to go if it wants to move up the international rankings.

China has the most EVs within its borders with a hefty 1,227,770 vehicles. The U.S. comes in second with 762,060 EVs.

If you scale these figures down to just battery-run cars instead of including hybrids, the numbers drop considerably.

China’s numbers drop to 951,190 EVs, while the U.S. numbers fall to 401,550 EVs.

Canada Ranks ninth in terms of battery-run vehicles, with 22,330 battery-only EVs.

In Canada, 5,168 of the country’s 5,841 charging stations are fast-charge capable. Go Compare didn’t note whether those 5,168 chargers are comprised of both level two and three chargers or just level three chargers.

By comparison, Go Compare found that there are 11,948 regular gas stations in the country.

Canada still has a ways to go in terms of charging infrastructure, but the good news is that both public and private entities are working to improve the situation.

While 5,841 seems like a lot of stations, it’s one station for every four to five EVs. The number also means that there is fewer than one charging station for every 100km of road in Canada.

Canada is notably one of the few countries with more fast-charging stations compared to slow charge stations.

For comparison, China has four stations per every 100 km which makes sense since it also has 213,903 chargers — the most in the world.

The US has fewer than one charger per 100km as well, even though it has 45,868 chargers.

Source: Go Compare

The post There are over 23,620 EVs in Canada and only 5,841 charging stations appeared first on MobileSyrup.

After getting a picture-in-picture (PiP) mode in October, it looks like Google is working on improvements for the new Chrome feature.

When the feature first launched, it lacked some rather essential pieces. For one, there was no ‘return’ button to send the video back to the tab it came from. Further, PiP lacked a ‘skip ad’ button, making it particularly frustrating on platforms like YouTube.

However, Google is working to correct those issues. According to TechDows, the Chrome team added a ‘Back to tab’ button in Chrome Canary version 73.

The button appears in the bottom right of the PiP windows and allows users to toggle the feature. Clicking it puts the video back in the original tab.

Additionally, Chrome Story discovered a recent commit made on the Chromium Gerrit, an online code collaboration tool. The code change seeks to add a ‘skip ad’ button to the PiP window.

However, the current implementation plan requires web developers to leverage the PiP code and include the ad-skipping button themselves, so it’s not clear if or how many websites will make use of it.

The commit also included a screenshot of how the button works.

Hopefully, video platforms like YouTube will be quick to adopt the button when it makes its way to a full Chrome release.

Source: Chromium Gerrit, TechDows Via: Android Police, Chrome Story

The post Chrome picture-in-picture feature to get ‘skip ad’ and ‘back to tab’ buttons appeared first on MobileSyrup.

Apple has allowed a handful of television manufacturers to integrate the AirPlay 2 standard into a total of 19 television sets.

AirPlay is Apple’s proprietary technology used to stream audio, video or pictures over the internet. The platform is effectively Apple’s equivalent to Google’s Chromecast technology.

While Chromecast is a tiny receiver that goes to the cloud and pulls media down to a Chromecast device, AirPlay streams media directly from users’ iPhones or Macs. In essence, both platforms function similarly.

As such, any Apple device can stream media or mirror its screen on a TV that has AirPlay 2. AirPlay-enabled TVs can also act as speakers in multi-room audio setups with AirPlay 2 speakers like the Sonos One.

All of the listed television sets, excluding Samsung’s, are now able to integrate with Apple’s HomeKit connection platform so users can ask Siri to turn their televisions on and off.

Only sets from Samsung, LG, Sony and Vizio plus the Apple TV set-top box support AirPlay 2. The full list of TVs is below.

• LG OLED (2019)
• LG NanoCell SM9X series (2019)
• LG NanoCell SM8X series (2019)
• LG UHD UM7X series (2019)
• Samsung QLED Series (2019 and 2018)
• Samsung 8 Series (2019 and 2018)
• Samsung 7 Series (2019 and 2018)
• Samsung 6 Series (2019 and 2018)
• Samsung 5 Series (2019 and 2018)
• Samsung 4 Series (2019 and 2018)
• Sony Z9G Series (2019)
• Sony A9G Series (2019)
• Sony X950G Series (2019)
• Sony X850G Series (2019 85″, 75″, 65″ and 55″ models)
• Vizio P-Series Quantum (2019 and 2018)
• Vizio P-Series (2019, 2018 and 2017)
• Vizio M-Series (2019, 2018 and 2017)
• Vizio E-Series (2019, 2018 and 2017)
• Vizio D-series (2019, 2018 and 2017)

Source: Apple

The post Apple website shows which new TVs are compatible with AirPlay 2 appeared first on MobileSyrup.

Facebook’s significant Messenger redesign — dubbed Messenger 4 — is widely rolling out to users via a server-side update.

The new design delivers, at least partially, on some of the social network’s promises. When Facebook unveiled the design at its F8 developer conference last year, it promised a more straightforward experience, as well as a dark mode.

While dark mode is mysteriously absent (for now), Facebook did simplify the Messenger app somewhat. For example, the new design reduces the number of tabs along the bottom bar from five to three. It also does away with the four tabs along the top of the app.

The three new tabs — ‘Chat,’ ‘People’ and ‘Discover’ — contain just about everything that was split across nine tabs before.

That being said, Facebook hardly trimmed excess features from Messenger. Instead, the social network moved them out of the way so users could focus on chatting. Most of those extras can now be found in the Discover tab.

Discover is split into two sections, ‘Businesses’ and ‘Games’ on Android, or ‘For You’ and ‘Businesses’ on iOS.

The For You and Games sections are practically identical, featuring several suggested games that users can play with their Messenger friends. The Businesses section is also functionally similar, offering a list of businesses users can message through the platform.

However, I can’t see people ever leaving the main Chats page. That section contains nearly everything users will actually need from the app, including current chats, a search bar to find contacts and Stories for those who use them.

New look, fresh hate

As for chats, not much has changed here either, beyond some new chat bubble colour options and the same general redesign. Like other big tech companies, Facebook opted for an all-white aesthetic. I quite like the look, and it feels like Messenger fits with the typical style of Android apps now.

opening up messenger after the new update like pic.twitter.com/vqZ7J6fT4M

— Abe (@NuanenBee) November 13, 2018

However, not everyone is of the same mind. Some users on Twitter have derided the lack of dark mode, but Facebook says that it’s coming soon.

Considering how much the company pushed dark mode as a selling point for the redesign, it amazes me the feature didn’t launch with the rest of the update. Further, I’m perplexed by the complaints of how bright the redesign is, as Messenger was always primarily white.

Other users have taken to social media to proclaim the “ugliness” of the app. While the new look might not be for everyone, I’d argue that it’s definitely an improvement over the previous look.

Ultimately, whichever side you fall on, you’ll likely see the update hit soon. After a few false starts early this morning, it appears the server-side update is making its way to almost everyone, so sooner or later your app will make the switch.

Source: Android Police

The post Facebook Messenger’s redesign is finally here and people don’t like it appeared first on MobileSyrup.

Tim Cook says Apple plans to launch new health-related services later this year.

In an exclusive interview on January 8th with CNBC’s Mad Money, Cook said Apple has been working on these new services “for multiple years.”

In August 2018, CNBC reported that Apple had hired more than 40 people to work at AC Wellness, the company’s wellness clinic. The clinic is a separate subsidiary of Apple but is dedicated to Apple employees based in Santa Clara County, Calif.

Apple hired on health providers, technologists, but not doctors. CNBC reported that most of these hires were nutritionists, exercise specialists and nurse practitioners.

“I believe, if you zoom out into the future, and you look back, and you ask the question, ‘What was Apple’s greatest contribution to mankind?’ It will be about health,” Cook said during the interview.

He added that the latest electrocardiogram-equipped (ECG) Apple Watch Series 4 is “democratizing” health care. The dedicated ECG app is the first of its kind in a consumer wearable and is expected to be released later this year, according to Apple. Though a Canadian release is still in the process as Apple is working with Health Canada to bring the functionality to the Canadian market.

In a September 2018 tweet, Health Canada said that it has not yet received a medical device application for the Apple Watch Series 4 with this health feature.

iOS 12’s latest feature called Screen Time, which was introduced at the 2018 WWDC developers’ conference, focuses on digital health.

“We are taking what has been with the institution and empowering the individual to manage their health. And we’re just at the front end of this,” Cook said in the interview. “But I do think, looking back, in the future, you will answer that question: Apple’s most important contribution to mankind has been in health.”

Image: CNBC video (Screenshot)

Source: CNBC

The post Tim Cook teases new Apple healthcare-focused services appeared first on MobileSyrup.

Safari Technology Preview Release 73 is now available for download for macOS Mojave and macOS High Sierra. If you already have Safari Technology Preview installed, you can update in the Software Update pane of System Preferences on macOS Mojave and from the Mac App Store’s Updates tab on macOS High Sierra. After updating to macOS Mojave, you may have to reinstall Safari Technology Preview.

This release covers WebKit revisions 239091-239566.

Web API

• Fixed navigator.userAgent in service workers to correctly reflect the customUserAgent set by the client (r239534)
• Fixed offsetLeft and offsetParent to adjust across shadow boundaries (r239313)
• Fixed an incorrect value for key property in keydown and keyup events generated holding the Control (⌃) key (r239361)
• Removed support for <meta http-equiv=set-cookie> (r239342)

JavaScript

• Added support for globalThis (r239464)
• Added support for BigInt in JSON.stringify (r239544)
• Implemented support for BigInt ValueDiv into DFG (r239158)
• Implemented DFG and FTL support for typeof in BigInt (r239141)
• Implemented the “well-formed JSON.stringify” proposal (r239537)
• Optimized Object.keys by caching key results (r239324)

CSS

• Fixed percentages in relative offsets for CSS grid items (r239502)
• Fixed thick overlines and line-throughs growing in the wrong direction (r239357)
• Fixed CSS variables to work for colors in the border property (r239516)
• Prevented attempting to animate invalid CSS properties (r239174)
• Updated CSS Properties and Values API to use new cycle fallback behavior (r239365)
• Updated repeated background images with zero size to display the background color (r239504)

Media

• Changed EME MediaKeySystemConfiguration distinctiveIdentifier and persistentState to default to optional (r239373)
• Changed inline WebVTT styles should override styles from Captions settings in System Preferences (r239181)
• Updated PiP video to switch tabs before returning video to inline (r239447)
• Changed playing a media element synchronously after setting srcObject to succeed without user gesture (r239189)
• Fixed a flicker when exiting element-fullscreen (r239475)

WebRTC

• Ensured the first video frame of a MediaStream is rendered (r239319)
• Fixed the MediaStream calculation of width or height when constraints contain only one of them (r239163)
• Ensured that an ended event fires on MediaStreamTrack when a USB camera is unplugged (r239531)
• Made RTCRtpSender.setParameters activate specific encodings (r239252)
• Made sure getSenders() and getReceivers() do not return closed transceiver senders or receivers (r239238)
• Implemented non-timeslice mode encoding for MediaRecorder (r239145)
• Made sure RTCRtpTransceiver.stopped is true when a remote description with the corresponding m section rejected is applied (r239192)

Web Animations

• Changed Web Animations to ensure an animation’s finished state only occurs once when updating animations (r239269)

Web Authentication

• Changed userPresence to always be true (r239523)

WebGPU

• Implemented WebGPUBindGroupLayoutDescriptor and its supporting dictionaries (r239288)
• Added basic implementation of vertex buffers with Metal Shading Language in WebGPU (r239139)

Web Inspector

• Enabled the display of m3u8 content as text in the Network tab (r239343)
• Ensured that localized strings in default audits respond to locale changes in the Audit tab (r239449)
• Fixed clipping of “Clear Filters” button in short windows in the Audit tab (r239394)
• Fixed descriptions of default tests in the Audit tab (r239433)
• Provided localization support for the display of “percentage passed” results in the Audit tab (r239404)
• Fixed autoformat for minified JavaScript (r239467)
• Fixed alignment of path view in the Canvas tab (r239312)
• Fixed initial focus state of the recording auto-capture input in the Canvas tab (r239420)
• Fixed selected text color when Inspector window is inactive in dark mode (r239386)
• Fixed colors of ThreadTreeElement status icon when hovered in dark mode (r239430)
• Fixed background color of Type profiler popovers in dark mode (r239484)
• Improved readability for tables containing object previews in dark mode (r239443)
• Fixed which element gets selected after pressing an arrow key after undoing deletion of a DOM node in the Elements tab (r239405)
• Fixed Charles Proxy errors when opening some HAR files exported from Safari (r239478)
• Fixed disappearing reload button after changing more than one setting (r239179)
• Fixed the spacing of “E” icon on the debugger dashboard (r239432)
• Fixed the rendering of column sort controls for dark mode in the Layers tab (r239385)
• Increased the default column width for some localizations in the Layers tab (r239345)
• Fixed the alignment of experimental setting editors for some localizations in the Settings tab (r239521)
• Fixed a problem in the Styles sidebar where focus was lost when the inspector is blurred (r239527)
• Fixed shift-clicking a color-swatch to change formats in the Styles sidebar (r239413)
• Fixed data corruption when toggling selected properties in the Styles sidebar (r239251)
• Improved the usability of the Computed styles sidebar when the panel is narrow (r239399)
• Made the “esc” key select the entire property when editing the name or value in the Styles sidebar (r239481)
• Prevented table selection from becoming corrupted when deleting selected cookies (r239175)
• Fixed labelling of Intersection Observer callbacks in the Timelines tab (r239397)

Facebook has started to remove content from the Yellow Vests Canada Facebook group after some users posted comments about killing Prime Minister Justin Trudeau.

Global News reported on January 9th, 2019 that the social media giant said it removed the comments because they violated Facebook’s community standards and that it was continuing to review the group.

The group’s administrators have told its more than 100,000 members to watch their language, telling Global News that the group does not “tolerate this kind of talk, and it will be dealt with.”

Some of the comments included statements like “Trudeau needs to be shot,” “Why hasn’t anyone shot him yet,” “Shoot the mother already.”

The Yellow Vests movement began in France as a form of political protest calling for economic justice reforms.

The movement made its way to Canada where thousands have marched in yellow fluorescent vests protesting the Liberal-led carbon tax, as well as delays in oil pipeline construction.

Protesters have been spotted in cities including Winnipeg, Calgary, Toronto, Halifax, Edmonton and Saskatoon.

On January 8th, one of the group’s members Josue St-Cyr, wrote everyone needs “to watch what they say about Trudeau.” He continued to say that members “might not mean it” when they comment against Trudeau “but the mainstream media will twist the meaning and try to make us look racist and criminal.”

Global News noted that the Royal Canadian Mounted Police (RCMP) are aware of the comments.

“We take all threats made against the prime minister very seriously,” an RCMP spokesperson told Global News.

In its online Community Standards guide, Facebook defines hate speech as “a direct attack on people based on what we call protected characteristics — race, ethnicity, national origin, religious affiliation, sexual orientation, sex, gender, gender identity, and serious disability or disease.”

Facebook says it provides “some protections for immigration status” and defines an “attack” as “violent or dehumanizing speech, statements of inferiority, or calls for exclusion or segregation.”

In May 2018, Facebook CEO Mark Zuckerberg told U.S. Congress that the company was looking into how to effectively use artificial intelligence to identify hate speech, but added that the process was very difficult.

Source: Global News

The post Facebook removing comments from Yellow Vests Canada page calling to kill PM Trudeau appeared first on MobileSyrup.

The City of Delta’s management continues their 20th century fascination with car culture. Last month I wrote about the extraordinary Council report  where the  Delta engineering department recommending concrete barriers to facilitate vehicular movement at 16th Avenue and 53A Street in Tsawwassen with solid double  yellow lines for car traffic at this “T” intersection. There have been a number of vehicles that have ended up in neighbours’ yards and  there is NO marked pedestrian crosswalk. Vehicles in Tsawwassen never stop for  pedestrians.

This residential intersection  is on a bikeway and pedestrian access point to a park, schools and to the commercial area, but no provision was made for vulnerable road users in this design. In fact the words “pedestrian”  and “cyclist” were not mentioned once in the report to Delta council.

Subsequent to our comment last month, this report was pulled  and the Delta Engineering Department has gone back to the drawing board. But not before temporarily plunking concrete barriers with tips that now preclude safe pedestrian travel on one of the corners of the “T” intersection.

Motordom reigns supreme with the City of Delta.