| import React from 'react' | |
| import { withRouter, Link } from 'react-router-dom' | |
| import { graphql, compose } from 'react-apollo' | |
| import { Formik } from 'formik' | |
| import Yup from 'yup' | |
| import FormWideError from '../elements/form/FormWideError' | |
| import TextInput from '../elements/form/TextInput' | |
| import Button from '../elements/form/Button' | |
| import { H2 } from '../elements/text/Headings' |
From time to time, Musk will send out an e-mail to the entire company to enforce a new policy or let them know about something that's bothering him. One of the more famous e-mails arrived in May 2010 with the subject line: Acronyms Seriously Suck:
There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.
That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary.
The Definitive Guide to Copywriting (Link)
Every product has a unique personality and it is your job to find it.
-
How would you describe the product? For this question, provide a simple, two to three sentence description of the product. It doesn’t need to be super long or detailed and don’t worry about providing a fancy answer. Simply write down a short description as if you were describing the product to a customer.
-
What’s unique/special about this product? The goal here is to identify something unique or special about the product. What does this product offer that others don’t? Is it made in the USA? Is it easy to install? Does it provide analytics that other sites don’t offer?
Apple will reject apps that are using private url schemes (Ugh, Apple....) if they are pretty much obvius. Some apps are rejected and others are not, so, be aware of this issue before implementing any of those URL's in your app as a feature.
- [UPDATE 4] iOS 10 update: apparently settings now can be reached using App-Pref instead of prefs
[UPDATE 3] For now you just can use url schemes to open your apps's settings with Swift 3.0 (Xcode 8). I'll keep you informed when OS preferences can be reached[UPDATE 2] The openURL() method of UIApplication is now deprecated. You should use application(_:open:options:) instead[UPDATE 1] Not yet tested in iOS 10. It will fail because of policies changes in URL scheme handling.
If you ever need a mobile application, you probably have an API endpoint to talk to. And if you're doing it right, you should have different environment for your API, usually it'll be: dev, staging, production.
We dont' want to perform test againts the production API. We need a way to teach our app to talk to different API environment. But what is the switch?
The naive way:
A non-exhaustive list of WebGL and WebGPU frameworks and libraries. It is mostly for learning purposes as some of the libraries listed are wip/outdated/not maintained anymore.
| Name | Stars | Last Commit | Description |
|---|---|---|---|
| three.js | 
I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).
A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.
And it was a dream!
All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.
And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go
