https://devcenter.heroku.com/articles/custom-domains http://thenomadicfreelancer.blogspot.com/2012/08/pointing-godaddy-domain-to-your-heroku.html
For each custom subdomain use domains:add
in the Terminal.
package com.blogspot.ksoichiro.linktest; | |
import android.text.Layout; | |
import android.text.Spannable; | |
import android.text.SpannableString; | |
import android.text.Spanned; | |
import android.text.TextUtils; | |
import android.text.method.LinkMovementMethod; | |
import android.text.style.ClickableSpan; |
import android.content.Context; | |
import android.content.SharedPreferences; | |
import android.preference.PreferenceManager; | |
public class PrefUtils { | |
/** | |
* Called to save supplied value in shared preferences against given key. | |
* @param context Context of caller activity |
https://devcenter.heroku.com/articles/custom-domains http://thenomadicfreelancer.blogspot.com/2012/08/pointing-godaddy-domain-to-your-heroku.html
For each custom subdomain use domains:add
in the Terminal.
Disclaimer: This is dumb. If anybody knows a better way, I'm all ears.
You have two Android projects. One is a library and one is an app that depends on that library. Both are on your local machine.
Now, say you want to test the library in the app before you publish it. Here's what you do.
You have an app and a lib:
# https://docs.docker.com/compose/yml/ | |
# Each service defined in docker-compose.yml must specify exactly one of | |
# image or build. Other keys are optional, and are analogous to their | |
# docker run command-line counterparts. | |
# | |
# As with docker run, options specified in the Dockerfile (e.g., CMD, | |
# EXPOSE, VOLUME, ENV) are respected by default - you don't need to | |
# specify them again in docker-compose.yml. | |
# | |
service_name: |
public class MutableHttpServletRequest extends HttpServletRequestWrapper { | |
private Map<String,String[]> parameters = new HashMap<String,String[]>(); | |
public MutableHttpServletRequest(HttpServletRequest request) { | |
super(request); | |
} | |
public void setParameter(String name, String value) { | |
parameters.put(name, new String[] {value}); |
Pode-se afirmar que no momento Promises são a forma mais "padrão" no momento de se tratar com
assincronismo no JS. Para quem trabalha com javascript, conhecê-las é essencial.
Uma dificuldade comum é que esta API tem uma curva de aprendizado um tanto acentuada de início, especialmente
se comparado com as alternativas mais antigas: callbacks e o módulo async
. No meu caso, levei ao menos uns 3
meses pra "cair a ficha".
-- na verdade promises ainda são um remendo para o problema do assincronismo do JS. Elas ainda possuem certa dificuldade
version: '2' | |
services: | |
myapp: | |
build: . | |
container_name: "myapp" | |
image: debian/latest | |
environment: | |
- NODE_ENV=development | |
- FOO=bar | |
volumes: |