nathanhammond

If you can read it, here's the same story happening in Hong Kong, but with outright fraud on the recipients' end.

https://thecollectivehk.com/%e7%a7%91%e6%8a%80%e5%88%b8%e8%a...

I did guess it was you; but wasn't sure. :P

You both are in violent agreement and it is amusing to see in the wild.

As an 外國人 who learned Cantonese as an adult (I moved to HK) I'm jealous of the quantity and quality of materials that exist for learning (not Cantonese). That being said, there are _enough_ materials so it's nowhere near as rough as e.g. Shanghainese.

My opinions on hard language reduces to "is this the first language you're learning from a particular language family?" If so, it's hard to learn. But "is ontologically hard" isn't something that I think is really worth ranking. Any four year old can speak their mother tongue just fine.

But the perception of "hard to learn" did work in my favor for learning Cantonese: as a 鬼佬 who speaks Cantonese I was given lots of latitude to be bad while learning because of that perception. And now I could go back and learn Mandarin now and it would be _much_ simpler than the task that I had in learning Cantonese.

That being said I still write in 口語. Slowly learning 書面語 as I read more and more of it.

Seeing your handle I am at risk of explaining something you may already know, but, this exists! And it was standardized in 1993, though I don't know when Unicode picked it up.

Ideographic Description Characters: https://www.unicode.org/charts/PDF/U2FF0.pdf

The fine people over at Wenlin actually have a renderer that generates characters based on this sort of programmatic definition, their Character Description Language: https://guide.wenlininstitute.org/wenlin4.3/Character_Descri... ... in many cases, they are the first digital renderer for new characters that don't yet have font support.

Another interesting bit, the Cantonese linguist community I regularly interface with generally doesn't mind unification. It's treated the same as a "single-storey a" (the one you write by hand) and a "two-storey a" (the one in this font). Sinitic languages fractured into families in part because the graphemes don't explicitly encode the phonetics + physical distance, and the graphemes themselves fractured because somebody's uncle had terrible handwriting.

I'm in Hong Kong, so we use 説 (8AAC, normalized to 8AAA) while Taiwan would use 說 (8AAA). This is a case my linguist friends consider a mistake, but it happened early enough that it was only retroactively normalized. Same word, same meaning, grapheme distinct by regional divergence. (I think we actually have three codepoints that normalize to 8AAA because of radical variations.)

The argument basically reduces "should we encode distinct graphemes, or distinct meanings." Unicode has never been fully-consistent on either side of that. The latest example, we're getting ready to do Seal Script as a separate non-unified code point. https://www.unicode.org/roadmaps/tip/

In Hong Kong, some old government files just don't work unless you have the font that has the specific author's Private Use Area mapping (or happen to know the source encoding and can re-encode it). I've regularly had to pull up old Windows in a VM to grab data about old code pages.

In short: it's a beautiful mess.

Is this published anywhere? Constraints I'm trying to solve for:

- Reasonable English corollary. (Doesn't have to be 1:1.)

- English-pronounceable Cantonese romanization.

- English-pronounceable Mandarin romanization.

- Doesn't diverge too much between the three.

- Characters that are identical in Traditional and Simplified.

- Pleasing to the relatives.

Nobody wants to leave Hong Kong. We're on the streets fighting for our home alongside people who love it just as much as we do. We have spent the past year gathering to sing, to celebrate, to mourn, and to fight for this place that we love. The past year has made it immensely clear how special a place Hong Kong is—even with the many things that can be improved.

This offer is appreciated and I believe that those who accept it as expedient will not be looked down upon by others. When you have the Sword of Damocles hanging over your head it is an exhausting existence. Many in the resistance will move overseas and continue their efforts.

From an economic standpoint, any emigration of Hong Kongers is likely to be beneficial to the places where they land. Those most likely to take this offer in the short term will coincide with those who are most materially wealthy. Given that the CCP has threatened to revoke the Chinese Nationality of those who accept an offer of this sort (and has been known to use family members as leverage), I do not expect that, as a sibling comment states, we would see people trying to use this as a tax avoidance scheme.

From a demographic standpoint, many of the people who will choose to leave are young. This is a significant benefit to many places in the world who have declining birth rates. The UK population pyramid, for example, would appear to benefit from immigration of a younger cohort. [1]

As to efficacy, there is a gap in coverage for those born shortly after the handover. It's unclear how many will fall into that gap but it does represent a cohort of people who tend more toward exclusively identifying as Hong Kongers. [2] People who qualify as dependents of BNO holders appear to be eligible so that gap may be approximately six years: July 1, 1997 - July 1, 2003. It also doesn't account for children of HK immigrants and I have no insight into those demographics and their opinions (possibly a significant number of mainland immigrants who identify as Chinese).

As a real gesture, instead of the words that have been spent accomplishing nothing for the past year, this is a welcome change. Hong Kongers are now hoping for 攬炒, "if we burn, you burn with us." But if nobody holds the CCP accountable it just becomes "we burn."

(I'm a US passport holder. I am a Hong Kong immigrant. My wife was born and raised in Hong Kong (土生土長香港人). I'm currently studying Cantonese full time at CUHK (中文大學). I have a 光復香港時代革命 flag hanging in my apartment. I wrote this quickly: there will be errors, glosses, and poorly expressed things. I do not speak for all Hong Kongers and their experiences, hopes, wishes, desires, and dreams.)

[1] https://www.ons.gov.uk/peoplepopulationandcommunity/populati...

[2] https://www.hkupop.hku.hk/pori_table_chart/EthnicIdentity/Q0...

I'm currently in Hong Kong and have been here since before the protests began. This saber-rattling has been ongoing. This is an escalation, certainly, but it is not a new message being sent to Hong Kong and it falls mostly on deaf ears. Over the past approximately two months:

- July 2019: With the pretense of preparation for the Chinese 70th anniversary celebrations, there were reportedly 190,000 police officers in Zhanjiang. [1]

- July 31, 2019: PLA releases a propaganda video showing military practicing riot drills. Notably it has English subtitles implying its target audience. [2]

- August 1, 2019: Approximately 12,000 police participated in anti-riot drills in Shenzhen. [3]

- August 13, 2019: Military hardware shown moving into Shenzhen. [4]

Everybody in Hong Kong already knows that their way of life is lost in the event that China gets involved. The Hongkonger's daily press conference said as much. [5] If either of the PLA or Shenzhen police become involved the outcome is predetermined, thus the relatively nihilistic mood. A local Hongkonger wrote this article for Dissent Magazine which also adds additional color. [6]

Responding to other comments, the fears of a Tiananmen Square type incident are likely unfounded given the prevalence of video from all of the ongoing protests. State Media Propaganda does not work when presented to a global audience. Any event of that nature would presumably be one economic gamble too far for the CCP.

*

[1] https://www.scmp.com/news/china/military/article/3020784/chi... [2] https://www.scmp.com/video/hong-kong/3020985/chinese-armys-h... [3] https://www.scmp.com/news/china/military/article/3021597/chi... [4] https://www.scmp.com/news/china/society/article/3022479/chin... [5] https://twitter.com/anti_elab/status/1161064639515389952 [6] https://www.dissentmagazine.org/online_articles/hong-kongs-f...

Ember A11y

We're making Ember accessible by default.

Monthly Goals:

  - Support Ember.js' internal upgrade to the new rendering engine.
  - Adopt dynamically scoped variables to make ember-a11y function.

Skills needed: Ember.js, Glimmer, Accessibility

Slack: https://ember-community-slackin.herokuapp.com/

Ember A11y: https://github.com/ember-a11y Ember A11y Addon: https://github.com/ember-a11y/ember-a11y

License: MIT

Ember CLI

We're building a tool that makes it easy to build and maintain Ember applications.

Monthly Goals:

  - Finish moving off of Bower and onto our npm infrastructure.
  - Upgrade our internal npm usage from 2.X to 3.X.
  - Make our story for caching using Broccoli far more efficient.
  - Improve the Node ecosystem's publishing patterns for the projects we use.

Skills needed: Node, npm. Familiarity with Ember.js & Broccoli unnecessary but a bonus.

Slack: https://ember-community-slackin.herokuapp.com/

Ember CLI: https://github.com/ember-cli/ember-cli

License: MIT

There is going to be some future work on some of the form elements. They're really not quite where they need to be.

1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad.

2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.

Here is a pretty complete list of significant Ember applications:

https://docs.google.com/document/d/1ZWYq3gwkPTzUiyqr4x_asSj8...

In general:

    how much code the browser needs to parse and execute on every page load

The caveat being that that code only needs to be parsed and executed once in a single page application.

    weight of execution payloads across operations in your app

Presumably this cost is providing value to the developer in terms of reduced development time, reduced complexity, or improved correctness. You shouldn't typically incur significant wasted cost in execution, just a selection of tradeoff. Besides, rendering to DOM is still the longest tentpole by far compared to microseconds for JS execution.

EDIT: With regards to the "independent test," that is in no way a realistic use case. You would never add items to the DOM individually when you're in that tight of a loop. You would instead build up a cache and write once. The only thing of consequence that is being measured in that benchmark is each framework's DOM insertion speed.

You're making an argument about callback aggregation. That is just one of the features that promises enable. The seminal article on the topic is Domenic Denicola's "You're Missing the Point of Promises." http://domenic.me/2012/10/14/youre-missing-the-point-of-prom...

Exactly what @rattray said. It's something you get nearly for free in data-binding world and is much harder to accomplish in imperative code. I wish you luck, and make sure you blog about it when it's done! (I want to see how it's implemented.)

Thinking about it more, I believe that my visceral reaction was to the imperative nature of the library. I was imagining trying to code something that generated a filter (e.g. PourOver.makeExactFilter("mythology", ["greek","norse"]);) and it seems like it would be unnecessarily complex without data-binding propagation/invalidation.

If I wanted to add "roman" mythology to that filter I would imagine something like:

    var mythologies = ["greek", "norse"];
    // ... create a collection with filters
    mythologies.push("roman");
    PourOver.makeExactFilter("mythology", mythologies);

But you don't get that last statement for free, nor the one where you join it into a collection, nor do I see a way to replace the previous mythologies filter. Any time you need to reprocess a filter you've got to run it through a series of imperative actions triggered from one of the events, and possibly throw away the collection and regenerate it (if you can't remove disjoint filters).

I would be pushing for a Object.observe/dirty checking/get-set version of this to take PourOver to the next level of utility. (?/Angular/Ember)

I much prefer a basic construct that makes it simple to do filtering and sorting that can be simply extended to any complexity. Sorting and filtering are really nothing more than set manipulation (which they state themselves) so with simple data binding this becomes a trivial exercise to build an impressive client-side search.

In Ember that might look like this:

    Ember.ArrayController.extend({
        filterA: Ember.computed.filter('fieldName1', function comparator() {}),
        filterB: Ember.computed.filter('fieldName2', function comparator() {}),

        joined: Ember.computed.union('filterA', 'filterB'),
        
        filtered: Ember.computed.uniq('joined'),

        sorted: Ember.computed.sort(function comparator() {})
    });

A long time ago when iOS dev tools were immature Joe Hewitt created https://github.com/facebook/three20. I can't find the source, but somewhere Joe is quoted that so many of the early Facebook application reviews were about how so much of it was derivative.

There is absolutely a place for this kind of library and if you pay enough attention to the details (sweat every pixel and animation) I fully believe that you can achieve an experience that would be completely indistinguishable from iOS.

Notes:

1. For this to work you should be using something like Ember as your front-end framework, not jQuery Mobile.

2. I'm not pushing this as dogma, I'm just very glad that it exists within the ecosystem.

Over-simplification: As a "not-bank" they can't engage in fractional reserve banking. This leveraging of money is what allows banks to truly generate profits. Acquire deposit assets at 1%, lend that same money out at 3-5%, profit on the spread. If a bank is offering a low rate that means that either their lending arm is not able to effectively use deposited capital or their overhead as percentage of that spread is too large. Higher rates signal that the bank is attempting to gain capital in order to supply their lending side.

Simple's funding likely only increased their runway while they were building a product that I'm guessing was net-negative. I don't feel like they could generate enough revenue to cover their burn rate using their holding bank strategy. If they could I suspect they would have continued down this path as a fearsome (future) competitor.

Once some bank builds the underlying technology in-house correctly they're going to be nigh untouchable.

This is an over-simplification. I'm also not entirely sure how much I can say, so I'm skipping things.

Most banks use what we term "bank-in-a-box" software provided by one of two vendors:

FIS - http://www.fisglobal.com/ Fiserv - http://www.fiserv.com/

In fact, just about the only ones who aren't using a complete bank-in-a-box solution are the megabanks, for example: BofA, Wells Fargo, Chase.

The upside of using a bank-in-a-box solution is that you can spin it up almost immediately and at very little cost (relatively). The downside is that you're running technology that, very often, was written last decade. For example: https://secure.ally.com/allyWebClient/login.do uses jQuery 1.3.2, released in 2009.

But worst of all, you can't really differentiate yourself from your competitors–they're using the same thing under the hood. In order to begin the process of differentiation you typically see banks progress through stages out of dependence upon these solutions.

1. First you enable service calls into the system of record (SoR).

2. Then you Balkanize your services, calling back and forth between your BiaB solution and your own custom component which reaches out to the SoR through services instead of the hosted, white-labeled BiaB. This is terribly slow. Remember what I said about last-decade technology?

3. Eventually a bank completely migrates completely to service calls on the backend to the SoR. But they still haven't implemented any of the reporting or back-of-house processing.

4. The ambitious banks then start trying to move the SoR and the back-of-house processing and reporting (this is a big deal) in-house. However, to work, this has to be a one-time switchover since "eventually consistent" is not a valid state for bank data.

Almost everybody stops before attempting Step 4. It starts getting expensive and hard really fast at that point–and almost no bank has that appetite for risk. However, even if you attempt Step 4, the legacy of your technical decisions has resulted in loosely coupled and often poorly integrated experiences wherein even pulling your data in-house likely doesn't fix it. At this point Step 5 is digging out of your technical debt, and I've yet to see any bank succeed at that.

Simple skipped Steps 1 & 2. They never incurred Step 5. They were insulated from Step 4 by using a holding bank. Step 3 was why they took so long to launch. On a technical level Simple is years ahead of every bank out there. Features they had the data for could be implemented in no time. Organizationally their mission was clear enough that everybody bought in. Their race, which I've said numerous times, was to catch up to Ally's marketing and deposit assets before Ally (or others) catches up to their technology. It's an asymmetric race, but not being a bank means that Simple couldn't leverage fractional reserve banking to its fullest which cuts into profit margins and makes it much harder to succeed. Their acquisition price implies to me that their burn rate was too high for their revenues to make the long game sustainable.

Contrast with BofA: "We spend, just overall, about $3 billion and change in annual technology development."

Ally's focus is on providing excellent rates which we have done by limiting our focus. That being said, you can look for tremendous changes in our technology story later this year.