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.

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.

$1.7 billion is a misleading number. The number that matters most in banking is your total deposit assets which they did not reveal in the blog post. The purchase was for two assets: the total deposits on hand (easy to calculate return on) and the technology. It's likely that at any bank of reasonable scale that it would take 2-3x the $117 million to build something comparable to what Simple already has. (I've worked at Wachovia, Wells Fargo, and Ally, and live in Charlotte so I know BofA's story too.)

This is an excellent purchase by BBVA, and a steal at that price. In short order they will move the assets over from the holding bank (that's the guaranteed money). At that acquisition price I suspect that Simple was struggling to return a profit since they were not actually a bank.

Ally's current app is built using http://www.kony.com/ which is why it is less than awesome. We're actively working to improve our native applications (and web experience), look for updates coming soon in your friendly neighborhood app stores. :)

Disclosures: I work at Ally and my team is building Ally's new online banking interface.

- Unlike Simple, Ally is actually a bank.

- We take deposits and then turn around and lend that money out primarily as auto loans.

- The rates we can pay are currently capped because we're still a TARP company.

Interface-wise there will be significant changes in the future (October-ish). Our entire online banking will be a single page application built using Ember, inspired by Simple. The transition will be ... interesting ... but after things settle down you can know that we're aiming to compete at least interface-wise in the space that Simple is in. (They have some fun things on the backend that we're not attempting yet.)

And if you look under the covers once we launch you'll notice that there is an API driving nearly everything. I wonder what might happen if that were, say, usable by others?

We started on this project using Ember 0.9.6 (though we've managed to keep up with HEAD) and much of our architecture is predicated on the toolchain choices we've made. Our first big task on our list after reaching feature-complete is to migrate to EAK, don't you worry. (We knew it was coming and adopted require to make it easier to migrate.)

I've edited it for clarity based upon my original comment. :) I actually rely on this behavior every day because the app I've built uses require.js to load values into the `App.` namespace dynamically.

That being said, now that you mention it, it seems far more likely that the issue was HTML vs HBS commenting. As an aside, what is the default behavior going to be for HTML comments inside of HTMLBars templates? That seems like a really weird edge case to decide how to handle (for developers).

Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though note that the Ember resolver will load code when you store it in `App.Foo(Controller|View|Route|...)` if that code is "needed" (say, by visiting the Foo route). So, unless you commented out the entire declaration it is entirely possible for that code to execute.

Spontaneously Changing Values: What was the key that you were trying to set? On what type of object (Route, View, Controller, etc.)? There are indeed some special values and it might be something that Ember can warn you of in the console as well as be documented. I'll be glad to make some documentation changes that make this issue easier to catch if you can provide me reproduction.

Godlike Refactoring: I work on a team with a widely distributed level of skills. One of my favorite features of Ember (which both has and will continue to save me hundreds of hours) is the fact that even if you make a mess of something you can generally come back and clean it up one piece at a time. My metaphorical description of this is that "all of the crap is in nice neat little piles instead of spread on the walls."

JavaScript.next: In the next/current version of JS both of these warts should be possible to resolve using Modules and Object.defineProperties(). I firmly believe that your complaints are not centered around Ember (which I honestly believe is insulating you from the worst of it) but instead from flaws in a language that was literally designed and built in an incredibly short time (my recollection is "a week" but I can't find a source).

(Edited for clarity based upon mixonic's reply.)

I've used it as you have for two things: - Storing user session data for high-use web applications. - High score tables.

And one more: - Storing diffs like those used for Google Docs (literally every change) for a real-time communication system.

The last one works by the client not getting a response and continuing to queue up its diff and send it once the server is back up. Manual conflict resolution is likely necessary after a drop in availability, but consistency is easy to figure out with monotonically increasing IDs.

From that same thread, the issue isn't with Ember, it's with V8. Ember itself is looking for a workaround to the issue.

http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

I posted about this almost two years ago (http://news.ycombinator.com/item?id=2443710) ... I am eagerly looking forward to DNSimple (http://dnsimple.com) entering the market as their own registrar (instead of reselling enom). Their founder has said that is a high priority goal for them this year which will immediately make them the registrar and DNS provider for all of my domains.

Oh, and don't use name.com, they hijack DNS. :)

This is part of a system called Passmark which was acquired by RSA many years ago.

As part of the newest releases of RSA's security approach it has been deprecated. In a few years you won't see this anywhere on the web (or, if you do, you'll know that the login and security portion of that site hasn't been looked at in years... also scary).

The banking industry is moving toward one-time passwords sent out-of-band and/or Google Authenticator for "something you have."

Ally Financial (http://www.ally.com) Charlotte, NC (Full time, on-site, relocation possibly available)

Our current online banking platforms (yes, plural) are hosted third-party solutions. We're building it in-house from scratch to be an API-driven JS MVC (Ember) application for cross-platform deployment.

This is where you come in: we're looking for a few developers who want to be a part of building something right the first time. The team building this is currently just me and two other people and we will be building everything forward of API consumption (UI dev, testing, & deployment across any imaginable platform). We'll be working with PhoneGap, Swagger, HTML/Handlebars, CSS/Compass/SCSS, JS, Ember, PhoneGap, Chef, Selenium, Mixpanel, Optimizely, and/or whatever other tools are right for the job (little is set in stone, we're in the prototype phase of the project). There are lots of jobs in other segments as well.

If you're interested, get in touch! nathan.hammond@ally.com