There are a grazillion lists of leadership qualities compiled by those who seem to be able to exactly define what it takes to be a leader. Yet, in my experience, the ability to lead is a shape-shifting un-bottle-able mist.
Nevertheless, here are four very general qualities that I reckon a good leader does indeed require, which I found myself think-doodling about during a presentation given by Hogan Assessments at the recent e-ATP conference in the Netherlands.
Skimming through my blog history looking for examples from my past of search thinkses, I came across several things I’d forgotten about; so as part of what may become and occasional series of posts that trip back in time, here are a couple of things I came across, one that imagined the future, another that is maybe revealing from the past.
I’m not sure how this would go down with my colleagues who still believe that everyone has a desktop or laptop computer, rather than a phone, tablet, Chromebook style computers (what’s the Microsoft equivalent?) as their primary computing device…
What do I really need from my operating system, if I’m doing everything through a browser?
…
Part of the point behind BOS [Browser Operating System] is that we expect to be online most of the time, ideally with a persistent connection. Once I have the BOS customised for my hardware set-up, I don’t really need a thousand and one drivers available, just in case I add a periheral [sic], if I know I’m going to be able to install the appropriate driver from the web.
What I see for BOS, therefore, is a simple, if hefty, installation profiling client that looks at my system, works out what’s there, gets the drivers I need, and bundles them for me with a single application – my heavyweight browser – in a customised BOS installer.
And that’s what I install.
Just one application – the browser. Only the drivers I need. And only the supporting functions I need to get the browser to work on my particular system.
Okay – so I thought that I’d still be plugging things into the computer and that it would require drivers for them… But the browser-centricity…? Hmmm… (for those of you who don’t particular following operating systems, see things like Chrome_OS.)
So, the second thing that caught my eye: the Facebook feed mixing desk, this time captured by the archive of the original OUseful.info blog:
Move the sliders and tune the content of your Facebook feed. What’s revealing about this is that the user was given some control over the ranking factors for posts that appear in the feed, along with an indication of what those ranking factors were.
So for folk who today don’t understand that the content they see is tuned (forgive the pun!) by Facebook algorithms, this provides a visual metaphor for what’s going on and who has the control. Because you can bet that: a) there are many more ranking factors now; and b) it’s up to Facebook how the faders are set. And it also hints at the oft unconsidered point: c) whose ear are the faders tuning the mix to?
This graphic was posted to twitter this morning by Brent Toderian. It comes from Dale Bracewell the Manager of Transportation Planning at the City of Vancouver.
Most people still think that widening streets and adding lanes for more cars will somehow help congestion. In fact that simply induces more traffic and makes matters worse. If more people chose to use bikes and walking for short trips – which are in fact the majority of trips in the city – there would be less traffic. What we need to concentrate on is the number of people being moved, not the number of vehicles. Using cars with a capacity of five or more people to move just one or two people is clearly a waste of space – not just the 3 metre lane width on streets but the parking spaces needed to accommodate cars when they are not being used – which is most of the time. There are far better uses for urban land than storing vehicles.
Clearly even if we cannot afford lots more skytrain lines, we could be moving lots more people if we had bus lanes in the City of Vancouver. There are not many at present, and most are peak hour, peak direction. The City cannot do very much by itself to increase transit supply but it could do a great deal to make the bus network much better. Exclusive bus only lanes and traffic light priority would straightforward to implement – but the noisy pro-car lobby would have to overridden.
At the risk of being pummeled by the Internet, I'll come out and say that Fall is the best season. I think this is a very different declaration from saying green is the best color or that silver is the best color for a handlebar. (Green as a color has a huge scope, so it can go with anything, and silver is the original and best color for bars - just for what it's worth.)
Fall here is very different from where I grew up. I lived out in the west coast for almost all of my life. We moved here about 8 years back and fall has only increased in it's magnitude while living here.
The view of the corn fields after the crop has been taken in
There's the sense of calm that comes over the Mid Atlantic when that first cold front of air comes down from Canada in September. It's a bit late this year, but still, I know that I can open up the windows and not have the sticky feeling of humidity enter into the house, but rather a cool, dry breeze that reminds me of trips to lakes up north and the cool breeze of an evening ride, trying to get home before it gets really dark.
I love the seasons here in the Mid Atlantic. There are four distinct ones here. Winter isn't that long most years and rarely very severe compared to other part of North America. Fall seems to last just long enough and I've usually got enough strength built up from riding in the summer that fall becomes easier.
The trees are in the midst of starting to drop their leaves/change their colors here. It's been dry here this summer, so that affects the timing I think.
Fall is a busy time of year. My wedding anniversary is in October, as is my wife's birthday, so lots of celebrations at the beginning and end of the month. The coffeneuring challenge starts in October and that always brings about a challenge to find new places to ride to enjoy a beverage. Throw in the Philly Bike Expo at the start of November, and all the work to get the booth created and gosh, before you know it, we're getting close to Thanksgiving.
Do you agree that Fall is the best time to ride? Or is there another season that tops it for you?
Last month we shared our view on the UK consumer credit market, and what it means for the loans you’ve invested in at Zopa. We also set up an email address performance@zopa.com to hear your questions. Thanks for all the emails that you have sent, we read them all.
In this post, we’ll give an update on our view of the market and look to answer some of the common themes in your questions.
Consumer credit outlook
We continue to monitor leading macroeconomic indicators carefully alongside how Zopa loans are performing compared to expectations.
The trends in the wider UK market we mentioned last month, like levels of defaults and personal insolvencies, remain evident. Within Zopa, our outlook for loans remains the same as our last update, meaning our expectations have not changed since August.
What we’re doing to manage risk
Many of the questions you sent to performance@zopa.com asked about what changes we’re making to our risk management approach, particularly in light of developments in the wider consumer credit outlook.
Since our last update, we launched our new credit risk scorecard. This is the model we use to assess the credit risk of borrowers applying for loans (which determines whether we accept a borrower or not, and if we do, what risk market they go into).
Our new model mixes proven traditional techniques with more cutting edge data science approaches that new technologies have unlocked, and replaces our previous model that we launched in April 2015. The new model not only uses more advanced techniques, but is also built on more data, and more recent data – all of which means it improves our ability to assess loans in today’s market.
Safeguard
We’ve also had some questions about how we will manage risk on non-Safeguarded loans once we retire Access and Classic.
Over the last 12 months 67% of our lending has been non-Safeguarded, and as of the end of last month, non-Safeguarded loans accounted for 64% of the whole Zopa loan book. So, managing risk on non-Safeguarded loans is something we’re already doing (and did from 2005 up until the launch of Safeguard in 2013).
Our principles remain the same, regardless of Safeguard. We still believe in prudent risk policies, diversification, and effective collections and recoveries policies.
As our expectations of defaults increased, we have increased our prices, so that the returns we target for investors in each risk market remain the same. Given the current climate, we’ve increased the mix of lower risk, lower return A-B loans in our products, which is why our target rates reduced.
Handling system failures during payment processing requires real-time identification of the issues in addition to offline detection, with the goal of eventual consistency. No matter what goes wrong, our top priority is to make sure that customers receive service for which they’ve been charged, and aren’t charged for service they haven’t received. Accurate payment processing is a crucial element in being worthy of trust, a core Dropbox company value.
In a standard system of this kind, failures might result in page load errors or a failed database transaction. System failures during a charge request can result in uncertainty about where the money for that request ended up: is it in our company’s account or still in the customer’s account? These system failures are extremely rare, but when processing as many transactions a day as Dropbox does, even a small probability can lead to multiple occurrences a day. Designing payments infrastructure that can resolve issues such as these is vital to keeping our customers’ trust and providing our finance team with accurate information.
In order to understand how system failures can disrupt payment processing, it’s important to understand each step involved in handling a customer’s purchase. When a customer visits the Dropbox website and elects to buy one of our products, we ask the customer to enter their payment information on the purchase form. After the customer submits the form, the system collects their payment information and securely sends it, as well as the amount we want to charge, to one of our external partners responsible for processing that type of payment information. For the purpose of this discussion, we’ll assume that the payment information in question is credit card information—not PayPal or other payment methods that Dropbox accepts. When our credit card partner receives the credit card information, they verify that the card is valid, store it for future charges (e.g. monthly recurring billing), and then attempt to charge the specified amount to the card. If the verification or charge fails, the credit card processor sends us a response containing a descriptive error code. In case of failure, we’ll refresh the purchase form, tell the customer that the charge attempt failed and ask the customer to try again. Otherwise, if the charge is successful, the credit card processor will respond with a success message as well as a token that we can use to reference the saved credit card for future charges. Upon receiving this success response, we store the payment result in our records. Finally, we will turn on the customer’s service—commonly called provisioning.
Successful Payment Transaction Diagram
As illustrated by the diagram above, we require communication with our external payment processor in order to complete the charge. This external communication involves side effects—changes in state as a result of the communication request. In particular, we care about whether money is moved from the customer’s account to the merchant’s account (Dropbox, in this case). In the presence of system failures, it can be unclear whether this occurred or not after making a request to an external system.
There are three main failure points of this charging system described above:
The network connectivity between Dropbox and the processor is disrupted causing communication timeouts or lost information. The result is either the external partner did not get our charge request or we did not get their charge response.
The external partner has an internal error or machine failure causing us to not receive a charge response from the processor.
We have an internal error or machine failure. Depending on the timing of this failure, two things could happen—either we are unable to send the charge request or unable to receive the charge response.
All of these failure scenarios result in one of two distinct situations:
The charge request is never processed by the external partner so no money is transferred. This is caused by either a) the network failing while the charge request is in flight to the external partner, b) the external partner has a system failure before they have a chance to process the charge request or c) we have a system failure before we send the charge request.
The money is transferred but not recorded in our system. This is caused by either a) a network failure from the external partner back to us so we never receive the charge response or b) a system failure on our side prevents us from processing the charge response.
In both cases, the core scenario is the same: a charge request was made but never marked completed in our system and is thus in an unknown state. After detecting occurrences of this scenario, the solution is to discover whether the charge request actually went through or not, then address this charge appropriately.
The Solution: No Charge Unaccounted For
Detecting Lost Charges
In order to detect incomplete charge requests, we record each charge request in our database before sending the information to our external partner. In this charge record, we store a customer identifier, the charge amount, as well as which payment processor the request will be sent to. The charge record also has a status attribute that tracks which part of the process the charge is in. Before we perform the charge, the charge record’s status is set to created. Next, we send the charge request to our external payment partner. When we receive the charge response from our partner, we update the charge record with a new status based on the response, normally either declined or successful.
Charge Request Status Transition Diagram
This status attribute of the charge request allows us to determine if a charge request was left in an unknown state. If the charge request has either the declined or successful status, then the charge response was correctly received and processed by our system. If the charge request has the created status, it’s necessary to look at the charge request’s creation time to figure out whether the request is in an unknown state or not. It’s possible that the charge request was only recently sent (milliseconds ago) and we could still get a charge response for it in the future. If the creation time is more than a couple minutes in the past (exact value depends on the timeout configurations) then we know that the charge request would’ve timed out by now so this request must be in an unknown state. To summarize, charge requests are in an unknown state if they have the created status and are more than a couple minutes old.
A common way to solve a lost request is to simply reissue the request. However, this is not safe when the request has effects that should only happen one time. Each charge request could result in money being transferred out of a customer’s account. We never want to charge the customer multiple times for the same item so reissuing the charge request is dangerous. Even if we refund the extra charges later, the customer still sees the funds momentarily taken out of their account and this breaks the trust we want to establish with the customer. Since we don’t have an infallible detection system for the previous charge request’s state, it’s safer to abort the purchase attempt. Therefore, the system doesn’t grant a customer their Dropbox service until we have confirmation of a successful charge. The important result of this design decision is that if we discover a charge was successful but we have no record of it due to system failures, then the payment needs to be refunded since we would not have turned on the customer’s service in this case.
Determining the Charge Status
Now that there is a way to identify the transactions in an unknown state and clear steps on how to handle them if the customer was charged, the next step in this solution is to discover whether the charge went through or not. The charge status can usually be discovered by communicating with the external payment processor. Most payment processors provide a convenient API to look up a charge’s status by either a merchant identifier or a transaction identifier. The merchant identifier, otherwise known as a merchant order number, is a unique identifier supplied by the merchant (Dropbox in this case) to reference this charge request. The transaction id, that we internally refer to as the external transaction id, is determined by the external partner at the time of the charge and referenced in the charge response. Thus, we will only know the external transaction id for a charge request if we received and processed the charge response. In the case of system failures, as discussed in the problem description, we do not receive a charge response so we do not have the external transaction id. That leaves the merchant order number as our only available option to perform an API lookup with. Since Dropbox formulates and sends the merchant identifier to the external payment processor, we have access to it at the time we’re making the charge request and store the value on the charge request record.
Using this merchant identifier, we do a lookup for matching transactions using the payment processor’s API. If a matching transaction is found, we update the charge request record with either a declined or successful status as appropriate based on the transaction’s status. On the other hand, if a matching transaction could not be found, we need another way to resolve the transaction status. This case is possible if the external payment processor has a system failure after they perform the charge but before they are able to record the charge in their own system. In addition, this case is also caused by an internal error on our side if the merchant identifier is not correctly recorded for the transaction so we are unable to use the merchant identifier with the processor’s lookup API. In the case when the lookup API cannot be used, the transaction’s status can still be found in the processor’s settlement files. Every payment processor offers settlement files available for download for each merchant that they service. These settlement files contain a list of every successful transaction that was processed on behalf of that merchant in addition to other information, normally split into 24 hour time periods. Each settlement record includes the external transaction id and merchant identifier fields mentioned earlier, so if lookup through the processor’s API fails, a search through the settlement file for a matching record may be successful. If a match is found, then the charge record’s status is changed to successful. If a match is not found, then the charge record’s status is changed to error to acknowledge that something went wrong during the charge request and we are unable to determine what occurred.
Additionally, the settlement file allows us to discover any successful charges which we have no record of due to internal bugs in our system or rare database failures. For this reason, we set up a background process which parses these settlement files and verifies that we have a charge record in our system for each settlement record. For any settlement record without a charge record, a charge record is created with information from the settlement file. With this process, we assert that all successful charges will have a corresponding record in our system. Note, this achieves the goal of eventual consistency since the settlement files arrive up to several days after the charge was performed and we don’t make the charge record until we have the settlement file.
Reversing a Successful Charge
Occasionally, a charge is successfully applied for a user but we aren’t notified about it right away and thus don’t provision service for the user. In such cases, we need to return the customer’s money as soon as we are notified by the payment processor of the charge. There are two ways to reverse a payment: voiding or refunding.
The decision of which method to use is influenced by many things. First, the cost of using an external payment processor involves fees that are assessed on each transaction that we perform through their platform. Voiding a charge, which is basically cancelling it, normally does not cost a fee. Refunding a charge, however, involves performing another payment in the opposite direction for which we need to pay a fee. Therefore, voiding a charge is cheaper than refunding the charge. Second, a voided charge will not show up on a customer’s end of month bank statement at all. Conversely, refunding the charge results in both the original charge and the refund payment being present on the bank statement. This could come as quite the surprise for the customer. From the customer’s perspective, the purchase form submission either returned an error or crashed with a 500 error (if an internal system failure occurred) and yet the customer sees evidence that we charged them. Even though we returned the money, this is still a negative experience for the customer. Third, if the charge request is successful and then we refund this charge later, there is a clear period of time between the charge and the refund during which the customer has less money in their account than they should have. Generally, this is a small amount of money but for some customers this could have a serious impact on their ability to complete other transactions while they are waiting for the refund. For these reasons, voiding is superior to refunding.
Unfortunately, the ability to void a transaction depends on the how long it’s been since the charge was completed. To understand why the timing matters, it is necessary to know the steps of fulfilling a charge request. When the payment processor receives the charge request, they record the request in their system, verify the payment information and then ask the credit card company to perform the charge. The credit card company responds that they accept the charge and apply it to the card. At this point the payment processor responds to us, the merchant, to say that the charge was successful. However, at this point, the payment is only “submitted for settlement” and the charge may not have settled on the card yet. Settlement means that the funds have been transferred and the charge can no longer be cancelled. For this reason, voids can only occur during the time window when the payment is in the “submitted for settlement” state, but not yet settled. This time window generally lasts less than 24 hours. If this time window has passed, then a refund must be performed instead.
Regardless of which method is used to reverse the transaction, once the reversal is complete, then our records and the customer’s account are now in the correct state. This combination of immediate mitigation and eventual consistency protects us from losing track of payments due to system failures which allows us to confidently assert that we are aware of all payments flowing through our system. This is just one of the ways that the monetization platform team makes sure that Dropbox is being worthy of trust.
Why does Dropbox need a Monetization Platform Team?
Thanks for reading our first blog post! The Monetization Platform team is based out of Dropbox’s Seattle office and we’re excited to share some of the things we work on. Learn more about the Monetization Platform team and why we exist in this feature story on The Muse.
This is an important project, led by my team in the Taylor Institute (go, Ykje and Samara!). We’re all looking forward to seeing what the grant recipients come up with this year.
OER grants fall under two streams: “adopt and adapt” and “create.” The former category consists of projects in which grant-holders redevelop existing materials for their OERs, whereas the latter involves the inception of an OER from the foundation up.
The OER Pilot has invited instructors to submit project proposals. In the adopt and adapt model, accepted projects are funded to allow for two undergraduate student researchers to apply two to three online resources with course- and lesson-based outcomes. At the same time, instructors employ graduate students to peer review resources for their project courses. Finally, faculty selects and decides on the most appropriate resource.
… 2017-18 OER Grant Recipients
Sharaz Khan, Haskayne School of Business
“Business technology management (BMTA 601)
Nicole Sandblom, Faculty of Science
“General chemistry for engineers” (CHEM 209)
Joanna Rankin, Cumming School of Medicine
“Introduction to disability and social theory” (CORE 209)
Elena Rangelova, Schulich School of Engineering
“Fundamentals of surveying” (ENGO 343)
Mayi Arcellana-Panlilio, Cumming School of Medicine
“Honours cell & molecular biology” (MDSC 351)
Maria Stoletova, Haskayne School of Business
“Business process improvement and creative problem solving” (MGST 741)
Jason Donev, Faculty of Science
“Introduction to energy” (PHYS 371)
Kathleen Hughes, Faculty of Arts
“Cognitive development” (PSYCH 451)
Elizabeth Montes Garcés, School of Languages, Linguistics, Literatures & Cultures
“Beginners’ Spanish II” (SPAN 203)
Catherine Wagg, Faculty of Veterinary Medicine
“An introduction to veterinary clinical pathology” (VETM 442)
I’ve got two presentations scheduled for October. The first is a free two hour seminar on scanning with a digital camera at the Click! Photo festival in Durham, NC. It takes place 10am-noon Oct 6. Here’s a link.
And I’ll be in New York at PhotoPlus, doing a tag-team presentation with Katrin Eismann called Preserving Your Photographic History. I’ll show how to scan with a digital camera, and then Katrin will demonstrate reparations and restoration techniques from her revised book on retouching. Here’s a link for that.
I sit next to a developer at my coworking location (I’m one of the many Mozilla staff who work remotely) who recently installed the new Firefox Quantum Beta on his home and work machines. I showed him what I was working on at the time (that graph below showing how nicely our Nightly population has increased in the past six months), and we talked about how we count users.
=> “But of course we’ll be counting you twice, since you started a fresh profile on each Beta you installed. Actually four times, since you used Nightly to download and install those builds.” This, among other reasons, is why counting users is hard.
<= “Well, you just have to link it to my Firefox Account and then I’ll only count as one.” He figured it’d be a quick join and then we’d have better numbers for some users.
=> “Are you nuts?! We don’t link your Firefox Account to Telemetry! Imagine what an attacker could do with that!”
In a world with adversarial trackers, advertising trackers, and ever more additional trackers, it was novel to this pseudo-coworker of mine that Mozilla would specifically not integrate its systems.
Wouldn’t it be helpful to ourselves and our partners to know more about our users? About their Firefox Accounts? About their browsing history…
Mozilla doesn’t play that game. And our mission, our policies, and our practices help keep us from accidentally providing “value” of this kind for anyone else.
Why? Why do we hamstring our revenue stream like this? Why do we compromise on the certainty that having complete information would provide? Why do we allow ourselves to wonder and move cautiously into the unknown when we could measure and react with surety?
Why do we make Data Science even harder by doing this?
Because we care about our users. We think about what a Bad Actor could do if they had access to the data we collect. Before we okay a new data collection we think of all the ways it could be abused: Can it identify the user? Does it link to another dataset? Might it reveal something sensitive?
Yes, we have confidence in our security, our defenses in depth, our privacy policies, and our motivations to work for users and their interests.
But we are also confident that others have motivations and processes and policies that don’t align with ours… and might be given either the authority or the opportunity to gain access in the future.
This is why Firefox Send doesn’t know your encryption key for the files you share with your friends. This is why Firefox Accounts only knows six things (two of them optional) about you, and why Firefox Sync cannot read the data it’s storing for you.
And this is why Telemetry doesn’t know your Firefox Account id.
Le Monde teste l’iPhone 8, qu’il trouve plutôt bien et conclut par cette phrase qui me fait hurler :
Ne nous mentons pas : en 2017, pour acquérir un excellent smartphone, un chèque de 800 euros n’est plus nécessaire. Samsung ou Oneplus proposent de remarquables smartphones Android aux environs de 400 euros.
Si l’on en croit Clubic, l’iPhone 8 coûte 247,51$ à fabriquer. Certes. Mais c’est oublier le coût de transport (par avion !) et le coût de distribution (il faut voir le luxe des Apple Stores et la marge des intermédiaires si on l’achète ailleurs). Il y a les frais d’homologation dans les différents pays.
Mais il faut aussi et surtout penser au prix du logiciel : système d’exploitation, applications Apple (Mail, Calendar, Plans, Photos, etc), et services associés, coûts qui sont assumés à 100% par Apple[1].
Vous me direz que Google a la même structure de coût avec Android, sauf que c’est faux. Si Samsung et Oneplus arrivent à sortir des smartphones Android à 400€, c’est d’un parce qu’ils n’ont pas un positionnement premium mais surtout parce qu’ils ne payent pas ni le système d’exploitation ni les applications associées, qui sont fournies gratuitement par Google en échange… de vos données.
La réalité, c’est que tout l’écosystème Android repose sur la subvention du logiciel et des services en ligne par le pompage de données personnelles. Si Samsung a Android et ses apps gratuitement, c’est parce que par contrat, il est obligé d’inclure les apps dans le téléphone et les mettre en avant. Ces apps (GMail, Calendar, Photos, Search, Maps & co) sont autant d’opportunités pour Google de pomper vos données !
S’il fallait résumer la situation, on pourrait le faire comme ceci :
Acheter un téléphone Android bon marché, c’est un peu comme si on le prenait à crédit en faisait un premier payement de 400€ et en payant quotidiennement avec ses données personnelles.
Forcément, payer un iPhone 800€ semble plus douloureux au début, mais au final ça revient moins cher.
C’est dommage que Le Monde, publication pourtant sérieuse, passe à coté de cette réalité, alors qu’il a le devoir d’informer ses lecteurs sur des sujets comme celui-ci. Attention, ça ne veut pas dire que j’idolâtre Apple : je trouve inadmissible la censure qu’ils exercent sur l’App Store. Mais sur les données personnelles, ils sont structurellement plus respectueux que Google et ses partenaires, dont le business model est fondé sur le pompage et l’analyse des données personnelles, le ciblage publicitaire.
Mise à jour du 2/10/2017
Certains commentateurs pensent qu’Apple et Google font la même chose en terme de collecte de données. Ils passent à coté que structurellement, Google a son ADN dans la collecte et l’analyse des données pour la personnalisation et plus que tout, la monétisation par la publicité ciblée.
Le boulot de Google, avant tout, c’est de vendre de la publicité ciblée. Tout le reste découle de cela. La vente d’appareils collectant les données est une suite logique de leur business central.
A contrario, le boulot d’Apple, c’est de vendre des gadgets haut de gamme innovants avec de fortes marges.
Certes, il est indispensable pour Apple d’offrir des services complémentaires qui touchent à la donnée (ne serait-ce que la sauvegarde en ligne) pour être compétitif, mais la collecte et l’analyse de la donnée n’est pas ce qui les fait agir. On le voit ensuite dans les technologies mises en œuvre par Apple pour protéger la vie privée. Secure Enclave, par exemple. Differential privacy, aussi. Le fait qu’Apple ait tenu tête au gouvernement américain lors de l’affaire de San Bernardino montre qu’ils sont capables de monter au créneau si nécessaire, même si c’est dangereux pour leur (très précieuse) image : oser affronter le gouvernement dans une affaire de terrorisme, c’était fichtrement osé (et nécessaire).
Quelques liens pour bien comprendre l’approche d’Apple sur la sécurité des données et la vie privée :
Back in 2014, we reorganized our privacy policies to make them simple, clear, and usable. That effort was based on simplifying the then 14-page privacy policy around a framework that retained some detail but helped users find information more quickly. We did this because of our Data Privacy Principles that offer us guardrails as we develop our products and services.
Today I’m happy to announce another revision of our Firefox Privacy Notice, which follows our initial announcement on the topic. We continue to build our products focusing on user control and fulfilling our “no surprises” rule when it comes to privacy. We believe that in context notices with the user experience in mind make notices more understandable and actionable for users. Our updated notice includes:
A layered design to show what we collect, why we collect it, where you can learn more, and what your choices are.
Language that is more specific and transparent when describing the types of data. We have used the same terms as our internal teams, including: “technical” data, “interaction” data, “webpage” data and “location” data.
A more holistic explanation of how a feature interacts with data. For example, we previously had a separate privacy notice for cloud features like Sync. This technical distinction was confusing, so we removed that separate privacy notice and have made it a part of the new Firefox Privacy Notice where context is more understandable.
On desktop platforms that support it, we have begun adding the ability to link the user directly into the appropriate user preferences so they can easily and quickly access privacy controls.
We’ve also changed our Firefox onboarding experience so that the Privacy Notice now displays on the second tab of a newly installed browser.
We hope all of this offers a more meaningful opportunity for users to learn about how we design privacy into Firefox, and make choices about the data they wish to share.
At the Rio Velodrome, a stunned silence engulfed the Hong Kong sports hacks as Sarah Lee Wai-sze crashed to the track, ending her strong hopes of improving on the bronze medal she had won in the keirin four years previously.
As she spoke to journalists, one broke down in tears – “Stop it or you’ll get me going too,” said Lee, choking up.
The tears were a reflection of what reporter and cyclist both knew – that the best chance of only a fourth-ever Hong Kong Olympic...
Programming languages seem to have different cultures, or communities, around them. I’ve noted in the past that there’s a distinct difference in the cultures around Ruby (for an example) and Haskell, and Matt Parsons summarized it neatly when he said:
Ruby community is v good about helping “build thing”; Haskell about “understand thing.”
I replied that I think this is to some extent because Haskell is, at its core, a coherent, understandable thing. Many other languages, including Ruby in my experience, have an ad hoc character to them – they were made to make things. They made design decisions based on what seemed useful and pragmatic to their makers and intended audiences. Indeed, I think this really gets to the heart of the difference (where, yes, it’s a continuum, not a dichotomy, don’t @ me) between the imperative paradigm and functional programming.
In the video called Haskell is Useless, Simon Peyton Jones talks about how Haskell was created for safety (purity, limiting effects) first, whereas most languages are created to be useful above all. Effectful programming is inherently useful – that’s why we write programs, generally, to be able to affect the state of the world in some way – but unrestricted arbitrary effects are also quite unsafe, particularly (though not only) when parallelism is involved. He notes in the video that useful languages are trying to move towards increased safety by restricting effects in various ways. Haskell, on the other hand, comes from a completely different idea of programming that emphasized safety first and then moved in the direction of usefulness.
You can certainly perform effects (and, indeed, you can be quite unsafe) in Haskell, but the type system enables a clean separation of concerns, a clean division between “pure” and effectful computations, and allows you to combine those into one program. The type system enforces this to a degree – I say “to a degree” because you can refuse to play along with this separation of concerns game and put everything inside a giant IO block like an imperative programmer. You probably won’t see much point in using Haskell if you keep writing code like that because it doesn’t make use of Haskell’s particular strengths, but you can.
So, the Haskell committee decided to be different from the outset and make a language based on some core ideas without worrying about being immediately useful, which gave it an inherent coherence. This central coherence in Haskell is why a lot of us come to love it. Certainly, as someone who learned Haskell despite having no interest in writing useful programs, that’s what I love about it. It also makes it hard and different from other languages, because it feels like you have to know the whole before you can really do anything with it.
This also led to the central difference in culture: Haskell people are helpful with understand thing because very often that thing wasn’t made for a specific purpose (e.g., monads do not exist for the purpose of performing effects) but is part of an overall system, based on a lambda calculus and set theory and their many improvements and developments (sure, I’m counting category theory as a development in set theory, fite me).
That system can be understood as a whole, and once you do, your understanding of Haskell will be powerful and allow you to build all the things. But it’s frustrating when people from “useful” languages want to know how to build thing and we don’t tell them that – we think we’re saying, “I will help you understand all this and then you can build the universe,” but they hear, “it’s impossible to build this thing without knowing category theory.”
You totally can build the thing without understanding the algebraic structures involved, but Haskell culture and its people are really, really into those algebraic structures and we really, really want to tell you about them. We’re like that person who needs to tell you their whole psychological history on the first date.
I’m no exception, and the algebraic structure I talk about the most passionately is the monoid. In a recent podcast, I talked about how I think understanding monoid and functor are the key vocabulary needed to understand Haskell as a whole, and I hope this has given some idea of why. And my next talk, at the Haskell Exchange in London on 12-13 October, is called A Monoid for All Seasons and is going to go into more detail about Haskell’s monoidal ecosystem that I hope will shed some light as well.
“unless you grow your own or are friends with a farmer with a sense of humor, you never see a potato or a carrot like these beauts. that’s unfortunate. in our modern mediated globelife we decry fakery in all it’s forms. no matter the field — consuming, political or social — we demand a semblance of honesty. and yet we also require the best, from everything and everyone. no matter the nature of things, we believe it’s natural that some things won’t make the cut. at some point fairness, candor, probity, bluntness, and integrity take a back seat to whatever we deem fine, fitting and just. easier on the eyes and all that. there are times though when it’s just plain considerate to pull back the veil to see a bit of what goes on when we aren’t looking.”
Which leads me to elsewhere on his site, where James writes:
Maneuvering daily through an increasingly global culture of capital bent on measuring success by material ownership, relative worth and fame, I am frustrated. Idealisms of this sort are by necessity exclusive. In our constant struggle to move forward, to achieve more, to rise higher, to be the best, to eventually be the only one…
And from that, to being the only one, in this poem by Louise Gluck:
Sparked by some of the reaction to the recent bike count, I thought it would be fun to look at a particular time segment (8:40 am to 9 am on Tuesday) with peak bike traffic, and this time count the cars.
In this particular segment, there were 237 bikes east bound (in the above image, the east bound bikes are going from lower right to upper left). During the same 20 minutes, I counted 162 cars. At first glance, it doesn’t seem to make sense since it looks like there are more cars on the road than bikes. However, in this image there are five bikes leading up to Brunswick and only four cars, with the bikes taking up much less room. An earlier count by Bells on Bloor indicated that about 80% of the cars during rush hour are singly occupied. This means that more people are being moved through the intersection by bikes than cars.
Put another way, even if the bike lanes were to be removed, and then two lanes of car traffic in the rush hour direction restored, if we were to move twice as many cars in the 20 minutes (a very generous assumption since some traffic is delayed by cars turning, etc), this would still be less than the number of people moved by the cars plus bike lane combination.
As an author, I get called on to do speeches from time to time. My Writing Without Bullshit speech is now connecting pretty well, based on how audiences are reacting to it. The reason is that, like my writing, it’s tight: every slide has a purpose, and most of those purposes have a payload. It … Continued
Blaise Pascal believed that the key error of the school of
philosophy known as
Stoicism
lay in thinking that people can do always what they
can, in reality, only do sometimes.
Had Pascal lived in the time of software development, he would
probably have felt the same way about Extreme Programming and
test-driven design.
I was reminded of Pascal the philosopher (not the language)
earlier this week when I wrote code for several hours without
writing my unit tests. As a result, I found myself refactoring
blind for most of the project. The code was small enough that
this worked out fine, and I didn't even feel much fear while
moving along at a decent pace. Even so, I felt a little guilty.
Pascal made a good point about Stoicism, but I don't think that
this means I ought not be a Stoic -- or a practitioner of XP.
XP helps me to be a better programmer. I do have to be aware,
though, that it asks me to act against my natural tendencies,
just as Stoicism encourages us not to be controlled by desire
or fear.
One of the beauties of XP is that it intertwines a number of
practices that mutually support one another, which helps to
keep me in a groove. It helps me to reduce the size of my
fear, so that I don't as much to control. If I hadn't been
refactoring so often this week, I probably wouldn't have even
noticed that I hadn't written tests!
One need not live in fear of coming up short of the ideal.
No one is perfect. I'll get back to writing my tests on my
next program. There is no need to beat myself up about one
program. Everything worked out fine.
There isn't a lot of detail in this article, but it's interesting to me because it represents the coming together of two strands in the Canadian online learning ecosphere (and specifically, Don Presant and David Porter, via CanCred.ca (Canada’s Open Badges Solution) and eCampusOntario respectively). "The overall goal of these action-based pilot explorations is to generate a diverse collection of case studies based on hands-on experience in designing and using Open Badge systems. These case studies will be used to inform future decision-making around potential shared services for open badges that will benefit Ontario’s post-secondary environment."
This paper (12 page PDF) is pretty loosely written but it within its evaluation of an open online course using a resourcwe storage system it offers a novel interpretation of connectivism to frame an evaluation of this system (and/or to evaluate the students using the system). "Connectivism can be understood in this way: the rapid change of knowledge foundation leads to decision change; the new information is gained continuously; the ability to distinguish important information and non-important information is crucial." The course was actually offered as blended learning, and was evaluated according to five criteria: participation, interaction, fitness, satisfaction and effect. The descriptions of each are unfortunately not very clear. Also worth noting is the conclusion that the blended learning environment did not support interaction very well. This accords with my own experience, specifically, that there is often better (and more) interaction online than in person.
The success of future Facebook paid content initiatives will depend to a degree on the success of this plan. It's a part of the general trend where social network services are trying to use their platform to sell subscription-based content. Perhaps the most significant to date is LinkedIn, which sells online courses through Lynda. But we can imagine Facebook, Apple, Google, Amazon and the rest to sell learning content, news content, and other content, through their platforms. But not all news outlets are participating - they want to market content directly to readers.
I’ll look forward to seeing (Vision Vancouver candidate) Diego Cardona’s six-home proposal on a single family (RS-1) lot. And whether it has any similarity to the four-unit idea for a 33-foot-wide lot I showed Neal Lamontagne last year which he then posted on Price Tags in April, 2016.
Be sure to peruse the 23 comments from some savvy folks such as Michael Mortensen, Frank Ducote, Thomas Beyer, jolson et.al. which are just as relevant today as they were last year. (Click here and scroll down.)
Of course, the number of units in that modest idea can easily be increased to Diego’s six homes by adding one more on top of each of the two structures shown, with just a few more feet of height added to today’s RS-1 height limit.
The key to any number of variations on this theme is to avoid getting hung up on density (FSR) as a number, increased from present 0.6 FSR to 1.5, 1.75 … take your pick … and then test it to arrive at an optimum but liberal maximum, recognizing the over-arching objective of delivering more housing supply.
And recognize that parking provision on site can and should reduced – no more than two spaces on a 33-foot lot (possibly three with a bit of a squeeze). Finally, anticipate and facilitate within the new zoning schedule the ability to strata title.
As reported in the Vancouver Courier the Musqueam First Nation is going ahead with the development of 21 acres of land they own close to the University of British Columbia. This comprehensive community will house 2,500 residents within four 18 storey highrises, townhouses and mid-rise buildings and will be called “Lelem”~”home” in the Musqueam language. Properties will be lease-hold with 99 year-long leases.A community centre, child care centre, grocery stores, restaurants, public areas and a park will be designed within this new community. The property is bounded by University Boulevard, Acadia Road, Toronto Road and Ortona Avenue and was given to the Musqueam First Nation in 2008 as part of a reconciliation, settlement and benefits agreement with the Province of British Columbia.
The Musqueam First Nation chose a developer for the first phase that has had a lot of experience in Vancouver, Polygon. Polygon is locally owned and operated for nearly 40 years, and the choice of Polygon was because of “leadership in design and development across all of their projects,” said Chief Wayne Sparrow in a news release.” The history of the Musqueam First Nation and their art will be a signature interpreted in this development. The development is expected to take ten years to build out and will create 1,900 jobs.
The Musqueam Capital Corporation will oversee the development of this land and has the former Mayor Michael Harcourt and Gordon Harris who is President and CEO of the Simon Fraser University Community Trust on their board. The chair of Polygon is Michael Audain who founded and developed the Audain Art Gallery in Whistler and supported the commissioning of the reconciliation pole at the University of British Columbia which was carved by Haida master carver James Hart and raised on the university’s main mall. This project is historically important as it is the first mixed use multi-family development undertaken by a First Nations in Metro Vancouver. Fittingly the principles espoused by the Musqueam for this new area focus upon community and belonging ““with a focus on global oneness and value for people and the environment.”
A game developed by an Ontario-based studio called Big-O-Tree (a play on the word ‘bigorty’)called Dirty Chinese Restaurant’ has been widely denounced as offensive and racist.
Players chase cats and dogs with a cleaver, scavenge for ingredients and dodge immigration officials in this “satirical” title that “in no way is meant to be an accurate representation of Chinese culture,” according to the game’s developers.
This type of racism has no place in Ontario. I know this does not reflect the values of the people of Markham. https://t.co/7VjeqyLLcD
The development studio — which is located in the Toronto suburb of Markham, Ontario — plans to release the game for iOS and Android devices. However, it’s unlikely that Apple will approve such an offensive title to be listed in its app store, given the digital storefront’s various approval policies. Google will most likely remove the game as well.
New York congresswoman Grace Meng has condemned a trailer for the game, stating that it “uses every negative and demeaning stereotype that I have ever come across as a Chinese-American,” according to the
Ontario Premiere Kathleen Wynne has also spoken out about the game on Twitter, stating that “this type of racism has no place in Ontario.”
Two trailers released about the game show its protagonist, Wong Fu, dumpster diving, avoiding tax collectors and sabotaging competing restaurants. The game’s first trailer also starts with the tagline, “because being politically correct is so… boring.”
In a statement posted to the game’s official website, the developers defend the project in a statement, saying that it’s satirical and should be compared to well-regarded satirical shows like South Park and The Simpsons, while adding that they “also listen to Jay-Z.”
“It has come to our attention that our small, independent game, Dirty Chinese Restaurant, has upset some people due to its content,” reads the statement in full.
“Our game is mainly satire and comedy influenced by the classic politically incorrect shows we grew up watching, such as: South Park, All in the Family, Sanford & Son, Family Guy, The Simpson, and Chappelle’s Show. We also listen to Jay-Z.”
Big-O-Tree games claims the studio was founded in August 2012, though it has never released a title, which could indicate the game doesn’t actually exist and is a ploy to create controversy. Along with the offensive game, the creators of the title — who seem intent on remaining nameless — have also released a series of equally offensive web comics based on their as-of-yet unreleased game.
Google could be working on a tabletop smart screen device designed for video calling and smart home features, according to TechCrunch’s sources.
The device is reportedly internally known at Google as ‘Manhattan’ and will feature a 7-inch screen that measures in at roughly the same size as the Echo Show. Unlike the Show, however, the device will offer YouTube, Google Assistant and Google Photos, along with video calling features comparable to Amazon’s display clad device.
TechCrunch says that its other sources indicate Google is working on a device with a larger screen designed to go toe-to-toe with full-sized televisions, though recent efforts have been focused on the company’s Manhattan project.
This new device’s target launch window is reportedly set for mid-2018, though there’s internal pressure for the device to release by the end of this year.
In terms of operating system, it’s believed the device will run Android in order to make it easy for third-parties to develop apps for it. Netflix also reportedly is very interested in supporting the device.
It’s worth mentioning that Amazon has yet to launch any of its smart home products in Canada, though the company did reveal a range of new devices earlier this week, including the 2nd-gen Echo, the Echo Plus a new Fire TV, and more. The Google Home remains the only smart home hub to be officially available in Canada.
Google has a hardware event set for October 4th, so it’s possible we could catch a glimpse of this still unannounced device by then.
Sphero has been a busy connected toy manufacturer over the last few months.
Along with the company’s Lightning McQueen toy, the Star Wars BB-9E remote control sphere, and its impressive miniature recreation of R2-D2, Sphero is also set to soon release the Sphero Mini.
While the tiny Sphero Mini shares many similarities with the second-generation Sphero 2.0 that was released way back in 2013, the smartphone-controlled toy also features a few surprising improvements over its predecessor.
The ball controls more accurately thanks to an improved app, which in turn offers a more responsive driving experience — though perhaps the Mini’s navigation improvements are also related to the toy’s smaller size.
Other upgrades include an impressive 10-metre range, the ability to charge directly via micro-USB and 45 minutes of playtime from one hour of change. In comparison, the Sphero 2.0 took three hours to charge and lasted approximately one hour.
Size-wise, the Sphero Mini measures in at 42mm in height, 42mm in width and a weight of 46g, allowing it to sit comfortably in the palm of most people’s hands. The device, which feels significantly slower than the Sphero 2.0, hits a top speed of 1m/s (approximately 3.6km/h), which is significantly slower than its predecessors approximately 7m/s (approximately 25.2km/h) speed.
Unlike the original Sphero, the Mini also features interchangeable shells in five colours: blue, green, pink, orange and white. The shells are easy to disassemble and they snap-off with minimal pressure, revealing the actual internal mechanism that powers the tiny toy.
This new feature does have some downsides though, including the fact that the Sphero Mini isn’t waterproof like its predecessor and that it doesn’t feel quite as durable.
This modular enclosure contains the same gyroscope and accelerometer technology that powered previous versions of Sphero’s app-connected ball. As a bonus, the Sphero Mini also includes tiny brightly coloured, fluorescent bowling pins and pylons that can be used as obstacles for the toy to navigate around.
Sphero has also made an effort to ensure that the Mini’s novelty doesn’t wear off as quickly as previous versions of the toy. For example, a new feature called Face Drive allows users to smile to make the toy move forward and frown to shift it backwards. Amusingly, making an angry face causes it to run away; and winking changes the Mini’s colour instantly. The toy can also be controlled with a virtual in-app joystick, or by tilting the smartphone, similar to Sphero’s other products.
On the game front, Sphero has added simple games to the Mini’s app, though none of them are particularly compelling. ‘Exile II’ utilizes the mini as a game controller in order to shoot down an in-game spaceship; ‘Lightspeed Drifter’ controls a futuristic ship racing through a tunnel and ‘Round Trip’ allows player to rotate the Mini to destroy bricks.
While these tiny experiences are a welcome diversion from aimlessly driving the Mini around, it would’ve been nice to see the company explore the augmented reality (AR) space when it comes to expanding the toy’s software options. Driving the Sphero Mini around an AR obstacle course would have been a lot of fun, especially with Apple’s ARKit and Google’s ARCore now out in the wild.
While the app isn’t available yet, the same educational features that the company eventually added to other versions of Sphero are also coming to the Mini in 2017 through a new coding-focused Sphero Edu app.
In general, much of the Sphero Mini is an incremental improvement over the Sphero 2.0, though the former’s significantly cheaper price tag could convince more people to pick up the smartphone-controlled toy. To put this price in perspective, the Sphero 2.0 costs $149 CAD, whereas the Mini version of the toy is priced at only $69 CAD. It’s worth noting that, if you enjoyed driving the Sphero 2.0 at high speeds, the Mini likely isn’t for you since it’s significantly slower.
Sphero says that the Mini is compatible with iOS 10 and above, as well as any Android device that features Android 5.0 and above.
The Sphero Mini is available now for $69 CAD at Best Buy Canada, as well as directly through Sphero.com.
Sparked by some of the reaction to 
