Profile

Cover photo
Daniel Yokomizo
Lives in São Paulo, Brazil
322 followers|192,288 views
AboutPosts

Stream

Daniel Yokomizo

Shared publicly  - 
 
 
SPLASH authors, please note (and pass on to your students):

I got a mysterious call this morning (from 800-217-4402) that asked me to confirm my attendance to SPLASH. It went to voicemail, so mostly because I was mystified, I called them back. (I don't plan to attend SPLASH and wanted to make sure I hadn't accidentally been charged for it; also, I wondered what new level of customer service the ACM had ascended to.)

It was a somewhat incoherent conversation (the person I talked to had a strong Eastern European accent, and there seemed to be cars honking in the background). They said they were calling because the Sheraton was running out of space, with only 50 rooms left. I told them I had no plans to attend SPLASH, which sort of surprised them; they wanted to know if anyone else from my organization would be going and if they could have their names. I told them to buzz off.

I looked up their number and found this:

http://www.ripoffreport.com/r/EHS-Exhibitors-Housing-Services/internet/EHS-Exhibitors-Housing-Services-Called-about-trade-show-hotel-accommodations-and-lied-abo-940698

http://whocallsme.com/Phone-Number.aspx/8002174402

http://www.scambook.com/company/view/129876/EHS-Exhibitors-Housing-Services

etc.

CC +Annabel Satin 
2 comments on original post
1
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
 
Fascinating. Some excerpts:

George Yancy: In your book “The White Racial Frame,” you argue for a new paradigm that will help to explain the nature of racism. What is that new paradigm and what does it reveal about race in America?

Joe Feagin: To understand well the realities of American racism, one must adopt an analytical perspective focused on the what, why and who of the systemic white racism that is central and foundational to this society. Most mainstream social scientists dealing with racism issues have relied heavily on inadequate analytical concepts like prejudice, bias, stereotyping and intolerance. Such concepts are often useful, but were long ago crafted by white social scientists focusing on individual racial and ethnic issues, not on society’s systemic racism. To fully understand racism in the United States, one has to go to the centuries-old counter-system tradition of African-American analysts and other analysts of color who have done the most sustained and penetrating analyses of institutional and systemic racism.

G.Y.: What then are we to make of the concept of American meritocracy and the Horatio Alger narrative — the rags to riches narrative?

J.F.: These are often just convenient social fictions, not societal realities. For centuries they have been circulated to justify why whites as a group have superior socioeconomic and power positions in American society. In the white frame’s pro-white subframe whites are said to be the hardest-working and most meritorious group. Yet the sociologist Nancy DiTomaso has found in many interviews with whites that a substantial majority have used networks of white acquaintances, friends and family to find most jobs over their lifetimes. They have mostly avoided real market competition and secured good jobs using racially segregated networks, not just on their “merit.” Not one interviewee [out of approximately 150 to 200] expressed seeing anything wrong with their use of this widespread system of white favoritism, which involves “social capital” passed along numerous white generations.
Racial discrimination is so embedded in our system that it has become nearly invisible. And there is data to prove it.
View original post
1
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
In case you missed it, we extended the BAHFest submission deadline. We need more proposals! Especially if you're in Seattle or San Francisco, please consider submitting one. We have some good ones so far, but we're hoping to get a couple more! Discuss this comic in the forum. July 23, 2015 ...
1
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
+Rahul Goma Phulore  Let's continue the REST discussion here.
1
Rahul Goma Phulore's profile photoDaniel Yokomizo's profile photo
2 comments
 
Then "go read it first, and then discuss" :) Seriously though, it's a very well written piece on software architecture, it discusses a lot about how one can figure out which architecture is better suited for a problem, given the existing constraints and what kind of trade-offs are made. For example, people complain about using hypermedia, or about how REST makes requests coarse rather than fine-grained and trash-talk it as a brain dead design choice, but in the thesis we find great passages like this:

"The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6). By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction."

----------------------------------------------------------------

I don't think this rant is about how REST is usually applied in the wild, the author explicitly states at the beginning: "However I see many deficiencies of REST and there are alternatives that work well for certain use cases. Obviously there is no one size fits all, I just want to emphasize that REST architecture is flawed in a number of ways." Even if we read this as implicitly saying only about badly designed "restful" systems, he lists a bunch of reasons that are plainly invalid.

----------------------------------------------------------------

When I talked about JSON schema, is the decision one can use if they want to use JSON. Nothing in REST forces you to use a particular hypermedia type (emphasis on hyper), as long as it's an appropriate format for your application domain and is in line with REST (from the thesis):

"REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability."

So one should use self-descriptive (which are inherently more bloated than formats that require schemas to be parsed) and standard (i.e. well-known by clients, intermediates, and the server).

People used xml a lot in the past, which had schemas since forever, and later moved to json as the fashion dictated a new season for curly braces as angle brackets went out of style, but if one blindly decides to use json and complains that it's schemaless (or ignores the existance of schemas, or complains about poor availability of such tools) then one is responsible for its own pain.

----------------------------------------------------------------

On pagination, search, filtering, etc., these are usually problems that people like to write their own solutions instead of using the correct ones. Both atompub and opensearch are more than ten years old now, born before than REST became trendy. Again, "Ignorantia normae non excusat".

----------------------------------------------------------------

In REST we emphasize resources because we are in a problem that has constraints that are aligned with the benefits REST as an architecture provides. It seems tautological, but the design of REST assumes we carefully evaluated our problem and our choices and our expert opinion chose a RESTFUL architecture.

So what benefits we get from "resourcing all the things"? A primary benefit is that in REST resources are the first-class citizens: they are identified (i.e. by URIs) and provide transitions to other interesting application states via actions (i.e. by forms/links). When something is a resource in REST it can be talked about, identified, modified, etc.. If we don't make an explicit loan approval resource then the system can't express the concept of a loan approval clearly and we would need to use out-of-band information (e.g. knowing that some actions of a loan resource are only applicable to the approval, etc.,).

What do we mean by application state? in REST an application is defined as:

"Since REST is specifically targeted at distributed information systems, it views an application as a cohesive structure of information and control alternatives through which a user can perform a desired task. For example, looking-up a word in an on-line dictionary is one application, as is touring through a virtual museum, or reviewing a set of class notes to study for an exam. Each application defines goals for the underlying system, against which the system's performance can be measured."

The approval of a loan in an application of a loan system and the application state is everything necessary to perform this application. The client navigates through the system trying to do this particular application and accumulates some state (e.g. the account related to the loan, the type of loan) about the process in a way that can later be given back to the server in a stateless request. The entire context of the application is supposed to be kept on the client until sent to the server (due to REST's stateless constraint). When the client send this state to the server it should send it via a representation of some resource, hence we need to identify the resource that is associated with that state. In this example either the loan resource or a new loan approval resource would end up being the target of the request. Assuming we choose the REST style wisely then our problem domain is well-suited for manipulation of resources and we can reasonably predict other clients will perform more applications on loan approvals (in a context that is not necessarily tied to the loans), for example reviewing the approval, adding comments, linking to other information (e.g. credit reports), transferring responsibility of the approval to a particular manager, canceling it later due to fraud concerns (e.g. by an automated subsystem), etc., and we figure out that making a loan approval a first-class citizen in REST means making it a resource with its own identifier.

If we decide that it's not worth the trouble we still would provide an appropriate action to the loan resource's hypermedia representation (e.g. an embedded link/form) that ends up pointing to the loan identifier. The client knows this is the appropriate transition not due to the structure of the action (e.g. it's target URI) but due to metadata in the action (e.g. the rel of a link) that is well-known and describes the semantic of the action. If later we figure out that the loan approval should be its own resource we just update this action and the client would still work exactly the same (for this application).

----------------------------------------------------------------

HTTP is a particular "implementation" of REST, so if we are using REST over HTTP (which is the most common scenario) we have some additional constraints. HTTP is an application protocol (here application has the usual meaning, from the one we used for application state) so we talk about HTTP concerns, like intermediaries (e.g. caches, proxies), and the user agent (e.g. the browser). All these other participants in the system have their own requirements and one of the is how to understand the requests and responses. Using standard headers and media types help a lot, but we need standard status codes for these participants to play well. The thesis talks a bit about how status codes play a role https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_1_2

When a request fails and we're using HTTP and we're using REST then we need to consider how other participants should interpret the response (e.g. caches invalidate the URI's state they're holding on a successful PUT) and how the user should interpret the response. When we return a 200 OK every participant knows that all is well, but the response body will be interpreted by the user, so two 200 OK responses could have in their bodies information that has different value to the user. In the case of user errors, we map those as a subset of client errors (the client in HTTP encompasses both the user and its user agent), so it'll be a 4XX. The particular 4XX depends on what happened, but actual user errors (instead of user agent errors, that is client programmer errors) are usually in four categories (interpretations from RFC2616 descriptions):

401/403 - Lack of proper authentication/authorization. User fixes it by giving appropriate credentials.
404/410 - The resource is missing, maybe it disappeared due to a concurrent modification.
405 - The method is not valid for the resource. This may or not be a permanent issue (e.g. trying to DELETE a resource that can never be deleted vs trying to DELETE something that can't be deleted right now due to some business rule). The user can't fix this one simply by modifying the request and trying again, if so it should be a 409. 
409 - The resource is in a state that the request would cause it to transition to an invalid state. For example, trying to withdraw more money from an account that does not allow overdraft. This kind of error should be fixable by the user in the request and resubmitted.

Other 4XX errors are essentially user agent errors.

Once you figure out how the user screwed up (e.g. lack of credentials, asking for more money than available) and put that in the status code you should then decide on how will the user be notified of the problem. Now it's time to pick the appropriate media type to use as the response body and craft a nice descriptive response, possibly with forms/links that fix the request in some way to resubmit it.

One should never have to spend more than a few seconds pondering the correct status code for a 4XX response, the time should be spent on crafting the appropriate response body.

----------------------------------------------------------------

IME people implement REST very badly and/or use it when they shouldn't. Also people assume one needs to use REST everywhere if they use REST somewhere in their systems. For example, I have some systems with REST+CQRS interfaces to external clients but internally they're implemented via pubsub, very clean separation of architectural styles outside and inside the surface.
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
Programmers know this productivity spell.
This comic/magic spell appears in the Summer 2015 issue of The Southampton Review. Thanks to editor Lou Ann Walker, and apologies to William Shakespeare.
1
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
 
Whatever you'd like to think, the minute we shall be able to improve future children genetically, it will get done period. You think billionaires won't go to China to have their kids' IQ boosted? Ah! The best you can hope for is to make it unaccessible for all but the elite. Next question: do you think you could ban gene therapies that improve adult's cognition,  muscle and bone strength, disease resistance.. Fat chance again! And, obviously, these technologies are coming. Just a matter of time.
83% of Americans say "changing a baby's genetic characteristics to make the baby more intelligent" is not "appropriate." But if such genetic modification proves possible (and safe for the baby), that lopsided poll result won't matter.
6 comments on original post
1
Sean McDirmid's profile photo
 
Anything to keep up with the computers. Given recent advances in deep learning, we might be closer to obsolescence than anyone could have imagined. 
Add a comment...

Daniel Yokomizo

Shared publicly  - 
 
 
Ethics for neural networks: my talk at IJCNN 2015. Gorillas, Wittgenstein's neural network, inceptionism and much more. http://aleph.se/andart2/ethics/ethics-for-neural-networks/
2 comments on original post
1
Add a comment...
Have him in circles
322 people
Marcos Contente's profile photo
Carlos André's profile photo
Tiago Suleiman's profile photo
José Dantas (Marido aluguel)'s profile photo
Lone Ffog's profile photo
krisztián kardos's profile photo
Software Engineering Radio's profile photo
OJ Reeves's profile photo
Gregg Lebovitz's profile photo

Daniel Yokomizo

Shared publicly  - 
 
GiveWell originally shared:
 
Has violence declined, when large-scale atrocities are systematically included? Commentary on The Better Angels of our Nature:

http://blog.givewell.org/2015/07/08/has-violence-declined-when-large-scale-atrocities-are-systematically-included/
Note: I wrote the following on my personal time, then cleaned it up slightly for public consumption. This post is not directly related to GiveWell's work, but we thought readers might find it interesting anyway. It provides a simple supplementary analysis to the argument presented in The Better ...
1
Add a comment...

Daniel Yokomizo

Shared publicly  - 
1
Add a comment...

Daniel Yokomizo
owner

Discussion  - 
 
 
Types for an untyped world... 
2 comments on original post
1
2
Dev Lila's profile photoIlya Yanok's profile photo
Add a comment...
People
Have him in circles
322 people
Marcos Contente's profile photo
Carlos André's profile photo
Tiago Suleiman's profile photo
José Dantas (Marido aluguel)'s profile photo
Lone Ffog's profile photo
krisztián kardos's profile photo
Software Engineering Radio's profile photo
OJ Reeves's profile photo
Gregg Lebovitz's profile photo
Basic Information
Gender
Male
Looking for
Friends, Networking
Relationship
Married
Work
Occupation
Just a Programmer
Employment
  • Just a Programmer, present
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
São Paulo, Brazil
Previously
São Paulo, Brazil - São Paulo, Brazil