Kids’ Video Game Obsession Isn’t Really About Video Games | Psychology Today
What Kids Are Looking For (And Not Getting)
Fortnite, like any well-designed video game, satisfies what we are all looking for. According to Drs. Edward Deci and Richard Ryan, people need three things to flourish. We look for competence — the need for mastery, progression, achievement, and growth. We need autonomy — the need for volition and freedom of control over our choice. And finally, we strive for relatedness — the need to feel like we matter to others and that others matter to us. Unfortunately, when considering the state of modern childhood, many kids aren’t getting enough of these three essential elements.
videogames  parenting  kids 
15 hours ago
GraphQL at Twitter
First, they measure query complexity. They assign a "score" (some point value) to each field, and calculate the total cost of a query. The total cost is the complexity of a query, and is calculated before execution. They then limit queries to some maximum complexity, and reject queries that are too costly.

Twitter also uses query depth measurement, which simply calculates the height of a query. For example, they could reject queries that goes further than 10 fields deep.

They don't allow arbitrary queries. All queries must be uploaded and stored ahead of time and exchanged for a unique key:

POST /graphql/eyBuaWNlIHsgdHJ5IH0gfQ
These are called stored operations or persisted queries. This protects against attackers exploring the GraphQL API or running introspection queries against it to find out what data is available or looking for vulnerabilities.
graphql  Twitter  APIs 
15 hours ago
api - Hyphen, underscore, or camelCase as word delimiter in URIs? - Stack Overflow
"You should use hyphens in a crawlable web application URL. Why? Because the hyphen separates words (so that a search engine can index the individual words), and is not a word character. Underscore is a word character, meaning it should be considered part of a word.

Double-click this in Chrome: camelCase
Double-click this in Chrome: under_score
Double-click this in Chrome: hyphen-ated

See how Chrome (I hear Google makes a search engine too) only thinks one of those is two words?

camelCase and underscore also require the user to use the shift key, whereas hyphenated does not.

So if you should use hyphens in a crawlable web application, why would you bother doing something different in an intranet application? One less thing to remember."
casing  delimiters  apis  design  Style 
Staying on Top of Changes in GraphQL | GitHub Developer Guide
"Staying on Top of Changes in GraphQL
May 3, 2018 xuorig
To provide a more seamless experience we prefer to continuously evolve our schemas rather than using API versioning. Continuous evolution allows us to iterate faster and provide our integrators with new schema members more often. We do our best to avoid breaking changes, but sometimes it's necessary to offer an unversioned API.

We strive to provide the most stable APIs to our integrators and to provide transparency about new developments. This is why we recently shipped the brand new Breaking Changes page, which announces future breaking changes to our GraphQL schema.

Internally, our engineers mark certain schema members as deprecated using a Ruby API on top of the graphql-ruby gem. Using the changes metadata provided by our engineers, we automatically compute removal dates and generate this breaking changes page, meaning you'll always get up to date information."
github  graphql  versioning  schemas  apis  omgwtf 
3 days ago
Breaking Changes | GitHub Developer Guide
"Breaking changes are any changes that might require action from our integrators. We divide these changes into two categories:

Breaking: Changes that will break existing queries to the GraphQL API. For example, removing a field would be a breaking change.
Dangerous: Changes that won't break existing queries but could affect the runtime behavior of clients. Adding an enum value is an example of a dangerous change.
We strive to provide stable APIs for our integrators. When a new feature is still evolving, we release it behind a schema preview.

We'll announce upcoming breaking changes at least three months before making changes to the GraphQL schema, to give integrators time to make the necessary adjustments. Changes go into effect on the first day of a quarter (January 1st, April 1st, July 1st, or October 1st). For example, if we announce a change on January 15th, it will be made on July 1st."
github  changes  apis  breaking  versioning  graphql  omgwtf 
3 days ago
GraphQL Best Practices | GraphQL
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.

Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.

In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API."
versioning  apis  graphql  schemas 
3 days ago
Getting Specific About APIs - Phil Sturgeon
API City 2018"
Nice overview from Phil about WeWork's process
apis  presentation  workflow  openapi  schemas  tools 
4 days ago
Frisby.js Overview · Frisby
"Frisby makes REST API testing easy, fast, and fun. Frisby.js comes loaded with many built-in tools for the most common things you need to test for to ensure your REST API is working as it should, and returning the correct properties, values, and types.
When you need something custom, Frisby.js also provides an easy way to customize and extend assertions to make your job easier, with less repetitive and tedious code.
apis  testing 
4 days ago
Sandbox - Quickly create REST API and SOAP mock web services
"Accelerate application development
Quick and easy mock RESTful API and SOAP webservices. Generate from API definitions,
instant deploy, collaborative build, and debugging tools for integration.
apis  design  mocking  testing 
4 days ago Beta
"RestPoint is a powerful prototyping technology to build and deploy REST API's with backend DB's, in the cloud, using a web browser, in minutes.

Use RestPoint to experiment and test drive API's, plug in real data, share API's with others to get feedback, all before final sign off to production."
mocking  apis  design  tools  SaaS  service  visual 
4 days ago
Rapido API designer
"Rapido is an API Academy tool that lets your rapidly sketch an API design."
apis  design  tools  visual  editor 
4 days ago
Node-based API mocking that can run in proxies
apis  mocking  tools 
4 days ago
stoplightio/prism: Turn any OAS (Swagger 2) file into an API server with mocking, transformations, validations, and more.
"The perfect OAS (Swagger 2) companion. Turn any OAS file into an API server with dynamic mocking, transformations, validations, and more."
apis  openapi  mocking  tools 
4 days ago
danielgtaylor/apisprout: Lightweight, blazing fast, cross-platform OpenAPI 3 mock server with validation
"A simple, quick, cross-platform API mock server that returns examples specified in an API description document. Features include:

OpenAPI 3.x support
Load from a URL or local file
Accept header content negotiation
Example: Accept: application/*
Prefer header to select response to test specific cases
Example: Prefer: status=409
Server name validation (enabled with --validate-server)
Request parameter & body validation (enabled with --validate-request)
Configuration via:
Files (/etc/apisprout/config.json|yaml)
Environment (prefixed with SPROUT_, e.g. SPROUT_VALIDATE_SERVER)
Commandline flags"
apis  mocking  tools  openapi 
4 days ago
Getting Specific About APIs
Client-side validation
Server-side validation
Client-library Generation (SDKs)
UI Generation
Server/Application generation
Mock servers
Contract testing"
From Phil Sturgeon
apis  design  contracts  openapi  docs  benetits  cicd  presentation 
4 days ago
Mike Amundsen tweetstorm
recaps the gist from the important chapters of Fielding's Thesis, mentions where GraphQl fits (and doesn't), and contrasts REST in the wider landscape of message exchange patterns. Fielding, himself, even pops in to clarify a point
apis  design  rest  graphql 
4 days ago
REST vs. RPC: what problems are you trying to solve with your APIs? | Google Cloud Blog
"If you ask most software developers why they define and build APIs, they are likely to explain that they have an application that is implemented as multiple distributed components, and those components call each other's APIs for the complete application to function. They may also say that they are implementing the API of a service that is used by multiple applications.

When developers design APIs to solve these kinds of problems, the solution characteristics they will typically prioritize are ease of programming for both the client and the server, and efficiency of execution. RPC is a good match for these priorities. RPC fits very well with the thought processes and skills of programmers on both the producer and consumer side of an API. Calling a remote procedure is usually syntactically the same as calling a normal programming language procedure, and learning the procedures of a remote API is very similar to learning a new programming library. RPC implementations also tend to be efficient—the data that is passed between the client and the server is usually encoded in binary formats, and the RPC style encourages relatively small messages (although some care has to be taken to avoid overly chatty interactions).

If RPC is such a good fit with the rest of software development, why is there another popular model for APIs—REST—and why is there so much controversy about which to use?"
apis  design  rest  http  rpc 
5 days ago
Protobuffers Are Wrong | Hacker News
Good commentary on a possibly-insightful-but-hateful post. Touches on JSON and GraphQL. Worth a read.
apis  protobufs  rest  json  design  dogma 
10 days ago
An apikey is like a social security number—simultaneously both an ID and a secret. While it may be convenient, it i…
from twitter
11 days ago - Open Source Economy
"Utopian is the only platform rewarding contributions to Open Source projects by utilizing a decentralised, vote-based reward system built on top of the STEEM Blockchain."
blockchain  opensource  community 
17 days ago
google/extra-keyboards-for-chrome-os: Extra keyboard layouts and input methods for Chrome OS
"A collection of extra keyboard layouts and input methods for Chrome OS. Each directory is its own Chrome extension."
chromeos  chrome  keyboard  keyboards  dvorak  compose  characters  typing  extension 
17 days ago
Layering Microservices
Interesting how APIs become rocks to experience clay

"In product development, the closer to the customer a piece of software is, the more often it changes. The services on the top of the stack are where product managers and marketers want to improve the experience, where designs need to be refreshed every few months, and where most of the experimentation happens. They naturally experience more churn than other services, and this gives us an opportunity to optimize components at this layer for fast-paced change.

Components at the bottom of this diagram, on the other hand, don’t change that often. Of course, at some point someone added an attribute to a group or to a user that wasn’t there before, but this was often a big deal, surrounded by careful change management and a migration strategy from the previous to the new state.

This dichotomy is big enough to justify its own layering model. I like to call this Clay-to-Rocks:

In this model, we group services based on how frequently we expect them to change. Clay is a nickname for software that is expected to change often, usually driven by the constant changes that a modern software product requires to stay relevant. Software at this layer isn’t meant to be brittle or unreliable, but the people building it will often prioritize iteration speed over performance or resiliency.

Rocks are how we call the underlying software that enables many different use cases, the software that is so close to the core business that it will probably only change if the business model changes. Many other services depend on services from this layer, which means that they should be built and maintained with resiliency and performance in mind.

Services are usually born as clay, as the team is experimenting with new products and features. If the experiment finds product/market fit, they are usually moved down as more and more newer products and features start building on them.

microservices  layers  APIs 
19 days ago
Dublin Microservice "Introduction to Service Meshes"
"While service meshes may be the next "big thing" in microservices, the concept isn't new. Classical SOA attempted to implement similar technology for abstracting and managing all aspects of service-to-service communication, and this was often realized as the much-maligned Enterprise Service Bus (ESB). Several years ago similar technology emerged from the microservice innovators, including Airbnb (SmartStack for service discovery), Netflix (Prana integration sidecars), and Twitter (Finagle for extensible RPC), and these technologies have now converged into the service meshes we are currently seeing being deployed.

In this talk, Daniel Bryant will share with you what service meshes are, why they are (and sometimes are not) well-suited for microservice deployments, and how best to use a service mesh when you're deploying microservices. This presentation begins with a brief history of the development of service meshes, and the motivations of the unicorn organisations that developed them. From there, you'll learn about some of the currently available implementations that are targeting microservice deployments, such as Istio/Envoy, Linkerd, and NGINX Plus."
microservices  presentation  meshes  istio 
19 days ago
Credit Offers Playground | Capital One DevExchange
demo creds, curl requests (with stub for SDKs), and sequence of getting token and then calling API
apis  tools  playground  capitalone  dx 
25 days ago
Best Practices for API Error Handling | Nordic APIs |
Excellent recap of what large API providers do with error responses for their APIs.
research  http  errors  apis  design 
26 days ago
Handling Errors - Graph API
They don't use HTTP error codes. GQL side effect?
"message: A human-readable description of the error.
code: An error code. Common values are listed below, along with common recovery tactics.
error_subcode: Additional information about the error. Common values are listed below.
error_user_msg: The message to display to the user. The language of the message is based on the locale of the API request.
error_user_title: The title of the dialog, if shown. The language of the message is based on the locale of the API request.
fbtrace_id: Internal support identifier. When reporting a bug related to a Graph API call, include the fbtrace_id to help us find log data for debugging."
facebook  apis  errors  design 
26 days ago
Jane Street Tech Blog - Putting the I back in IDE: Towards a Github Explorer
"Imagine a system for editing and reviewing code where:

Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it.

Within your editor, you can pull up a global view of all your branches, your outstanding pull requests, and the pull requests you’re assigned to review. It’s one keystroke to view the summary for a pull, and one more to start editing any of its files right there under your cursor.

Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on."
ide  tools  development  git 
26 days ago
RT : Wanted to share sneak-peak 'pic' of the fun we'll be having next week at . Register today and join the cho…
apistrat  from twitter
29 days ago
config/ at master · lightbend/config
"HOCON (Human-Optimized Config Object Notation)
This is an informal spec, but hopefully it's clear.

Goals / Background
The primary goal is: keep the semantics (tree structure; set of types; encoding/escaping) from JSON, but make it more convenient as a human-editable config file format.

The following features are desirable, to support human usage:

less noisy / less pedantic syntax
ability to refer to another part of the configuration (set a value to another value)
import/include another configuration file into the current file
a mapping to a flat properties list such as Java's system properties
ability to get values from environment variables
ability to write comments
Implementation-wise, the format should have these properties:

a JSON superset, that is, all valid JSON should be valid and should result in the same in-memory data that a JSON parser would have produced.
be deterministic; the format is flexible, but it is not heuristic. It should be clear what's invalid and invalid files should generate errors.
require minimal look-ahead; should be able to tokenize the file by looking at only the next three characters. (right now, the only reason to look at three is to find "//" comments; otherwise you can parse looking at two.)
HOCON is significantly harder to specify and to parse than JSON. Think of it as moving the work from the person maintaining the config file to the computer program."
config  json  syntax  configuration 
4 weeks ago
RT : Hey community! is moderating a panel in Nashville next week on the future of the with…
API  OASv3  from twitter
4 weeks ago
Wow, that brings back memories! I have to admit that working on the menu system for NCAA Foo…
from twitter
4 weeks ago
Max Diff Analysis for Market Research | SurveyAnalytics - Online Survey Software
MaxDiff is an approach for obtaining preference/importance scores for multiple items (brand preferences, brand images, product features, advertising claims, etc.). Although MaxDiff shares much in common with conjoint analysis, it is easier to use and applicable to a wider variety of research situations. MaxDiff is also known as "best-worst scaling."
surveys  uxr  research  featuers 
4 weeks ago
(10) I Like, I Wish, I Wonder | LinkedIn
"The concept is simple. The team stands in a circle and discusses the past week, the only restriction being that each person must start his or her statement with “I like…”, “I wish…” or “I wonder…”. It is recommended to keep the statements succinct and to avoid responding till the end of debrief. Lastly, any topic of interest is fair game.

So, here’s an example of a hypothetical Friday debrief:

“I like that we had sushi for lunch yesterday.”
“I wish that we all looked at metrics daily”
“I like that our daily activations are increasing”
“I wish that we kept our bathrooms cleaner”
“I wonder if the sun’s going to come out today”
“I wonder if Apple is going to approve our iOS app anytime soon”"
feedback  patterns  criticism  techniques 
5 weeks ago
Tragedy of the Commons Clause – tecosystems
Unsurprisingly, the record companies and their trade organization, the RIAA, were appalled at their products being shared user-to-user for free rather than purchased directly. In their eyes, their formerly paying customers were all thieves, not would be buyers who merely wanted a simpler, more convenient way to purchase music digitally. As a result, their response to this disruptive threat was not to offer users what they wanted: an online purchasing offering. Instead, they attempted to further restrict the digitization of physical media such as CDs, they employed advertising scare tactics and eventually litigation of their would be customers. They saw licensing and enforcement as the solution to a business model problem, in other words.

Commercial open source organizations who are considering licensing as a solution to their business problem, then, might want to focus not on whether Amazon is taking advantage of open source software, but why customers are flocking to Amazon and other cloud providers. Whether or not one believes that cloud providers can and should do more to support the open source projects – and the view here is that it is inarguably the case – is immaterial. Ultimately the problem faced by commercial open source organization is less the fact that the open source licenses they rely on are too liberal than the fact that customers want what many commercial open source organizations are unable or unwilling to provide: a managed service. Licensing cannot address that problem.

As has been said here before, licenses are always a tactic, but they’re rarely a strategy. If the Commons Clause is intended to “protect” open source but is both not open source itself and widely viewed as actively harmful to it, it’s not clear how much protection the industry needs.
opensource  licenses  redis 
5 weeks ago
My Experiences in the Haitian Earthquake • Andrew's Blog
Andrew's account of being in Haiti during the earthquake with James Tamplin
haiti  earthquake 
5 weeks ago
How to choose the right UX metrics for your product
"The HEART framework
While helping Google product teams define UX metrics, we noticed that our suggestions tended to fall into five categories:

Happiness: measures of user attitudes, often collected via survey. For example: satisfaction, perceived ease of use, and net-promoter score.
Engagement: level of user involvement, typically measured via behavioral proxies such as frequency, intensity, or depth of interaction over some time period. Examples might include the number of visits per user per week or the number of photos uploaded per user per day.
Adoption: new users of a product or feature. For example: the number of accounts created in the last seven days or the percentage of Gmail users who use labels.
Retention: the rate at which existing users are returning. For example: how many of the active users from a given time period are still present in some later time period? You may be more interested in failure to retain, commonly known as “churn.”
Task success: this includes traditional behavioral metrics of user experience, such as efficiency (e.g. time to complete a task), effectiveness (e.g. percent of tasks completed), and error rate. This category is most applicable to areas of your product that are very task-focused, such as search or an upload flow."
analytics  design  management  metrics  ux 
7 weeks ago
San Francisco Waldorf School - News Viewer
Sir Jonathan Ive's Inspiring Message to Students

Jony Ive spoke with our high school students this semester. Here are excerpts from that discussion.

* * *

I've never done anything like this before. I'm here because it's San Francisco Waldorf School and my family has been part of this school for many years.

I thought I would be brutally candid about my roots and where I have ended up. When I was about your age or a bit younger, I became very aware of two things. The first was that, through traditional eyes and in terms of academic achievement, I was a shocking disappointment to my teachers and my parents. Compounding that, I was terribly, terribly shy. I struggled; I could not speak in front of a group of people of more than four or five without turning bright red and my voice shaking. It was very debilitating.

The second thing I became aware of (and thank goodness the awareness happened about the same time) was what I loved doing. I had a teacher who told me that the most important thing is to figure out what makes you happy and joyful. I loved to draw; what a wonderful thing to discover.

In England, there is a very clear system – I think it's not the same here in the US – in which you aspire, really, to be an attorney, dentist, or doctor. If you're good at mathematics and the classics, preferably Latin, you're held in esteem. And if you're good at art – drawing and making things with your hands – you're seen... well, at least you're not getting into trouble. If you were good with your hands, the inference was that, well, you're stupid with your brain.

So I found that I loved to draw but I wasn't drawing for the sake of drawing, like some students who went on to study fine arts. I was drawing to help me think. I was exploring things that were three-dimensional and drawing to figure things out. I had a very fertile imagination and I wanted to make things. That's the realm in which I worked. It didn't help my shyness but it was clearly my passion and I discovered that I was relatively competent.

* * *

I grew up in a very poor part of London and went to college in the northeast, to Newcastle, which had an amazing art program – great graphic design, industrial design, and fine arts programs. Then I went back down to London and became what is known as an industrial design consultant. I worked independently for different companies. Oddly, there were two big companies that I ended up working for. One company called Ideal Standard, which you might know as American Standard, makes toilets and washbasins. So I designed toilets. And then also, there is this company out in California called Apple.

When I was in college in the '80s, the use of computers just started to become popular. I loved my drawing and I loved my pencils, and the computers were terrible. There is a funny thing about technology: if you struggle with it, have you noticed that you blame yourself? If you eat something and it tastes bad, you don't blame yourself, do you? You think: whoever cooked the food made it terribly. So I sort of resented the use of computers until the Mac came out. It just blew me away and I had a wonderful sense that it's not me, the other stuff was just rubbish.

I suddenly realized: what you make, your work, is a representation of you. Isn't it? What you make testifies to what you think is important and what you think is not important. It testifies to what you care about and to the direction of your gaze. Everything in this room has been designed; every chair and every table has been made to a price and to a schedule and to someone's aesthetic beliefs. This was a profound discovery for me: what we do will point back to us. I found that inspiring and a little intimidating. I had a sense of the group of people who had the audacity and ambition to make this computer. I was going to find out about this group of people I didn't know anything about. In hindsight, it was an enormously arrogant assumption because I really didn't know very much at all.
* * *

There are certain categories of products. The form of this stool, for example, describes what it does. So you understand that I am holding a stool and not a piano or a washing machine or a computer because what it looks like is what it does. The fancy-pants way of describing that is "forms follows function."

With the Industrial Revolution, a new category of product with complicated mechanisms started to develop. The mechanisms may not be overt and the use of the product is far less obvious. I put computers into this category; their insides are a complete mystery to many people and design presents a huge challenge.

* * *

The design team is a very small team. Everybody has an obsession with making things and how things are made. The one thing that people have in common is curiosity. I can work with anybody who is light on their feet and curious and inquisitive. I think it's a lovely thing to be wrong. Not all of my colleagues feel the same way, but I love it when I'm wrong and I'm surprised. I take huge delight in it.

Taking time and being precise and thinking about your goals is very important. When I'm designing something, I spend a lot of time being careful with language. For example, if I say I'm going to design this stool, immediately just that word 'stool' has huge connotations. It predisposes you to think in a certain way. If I say, I'm going to design a support system that holds me so many feet above the ground, well, that will make me think an entirely different way. So just the way you use language is terribly important. It predisposes you to think in a certain way.

There's a great George Bernard Shaw quote about how all progress depends on the unreasonable man. It's brilliant: newness exists because you've said no to reason. And if you have an idea, then to turn that idea into something that's real requires an incredible drive.

Sir Jonathan (Jony) Ive is a visionary in the field of industrial design. As Apple's Chief Design Officer, Jony is in charge of groundbreaking designs such as the iPhone, iMac, and iPod that have revolutionized the way we interact with technology and each other. He holds more than 5,000 patents and several honorary doctorates, and his work is featured in the permanent collections of museums around the world, including the Museum of Modern Art in New York. A native of London, Sir Jonathan Ive was made a Knight Commander of the British Empire in 2013 "for services to design and enterprise." Jony is also a member of our SFWS community.
design  Apple  sanfrancisco  waldorf  jonathan_ives 
8 weeks ago
« earlier      
!to_read addon advertising advice ajax amazon analytics android api apis apps architecture art article audio authentication backup blog book bookmarklet books browser business change chrome code cognition collaboration communication community comparison cool copyright creativity css culture data design development diy documentation economics editor education elearning email environment examples extension extensions facebook family favorite feedly finance firefox flash flickr food for free freeware fun funny future games generator github google graphics green hack hacks hardware health history home howto html http humor identity ifttt iftttfeedly iftttgr images information innovation inspiration interesting interface internet javascript jquery json kids language later law learning library life linux list lists lsi mac management map mapping maps marketing math media metrics microsoft mobile money mp3 music network online opensource organization osx parenting patterns pdf performance philosophy phone photo photography photos php plugin politics presentation privacy productivity productmanagement programming psychology read recipes reference research resource resources rest rss ruby sanfrancisco saved science script search security service sharing shopping social software startup startups statistics storage strategy sustainability teaching technique technology testing text time tips tool tools tracking travel trends tutorial twitter ubuntu ui usa usability useful utilities utility ux via:pocket video visualization web webdesign webdev wiki windows word wordpress writing xp youtube

Copy this bookmark: