Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.
An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.
Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty
Implemente uma função que recebe como parâmetro uma string contendo um texto que deverá ser quebrado em múltiplos tweets que serão postados em forma de thread no Twitter.
- Cada tweet deve conter, no máximo, 280 caracteres.
- Caso o texto tenha que ser quebrado em múltiplos tweets, o final de cada tweet deve exibir a contagem do progresso da thread. Isto influencia na contagem total de caracteres do tweet. Por exemplo:
The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.
This means you have the following choices:
- Use ESM yourself. (preferred)
Useimport foo from 'foo'instead ofconst foo = require('foo')to import the package. You also need to put"type": "module"in your package.json and more. Follow the below guide. - If the package is used in an async context, you could use
await import(…)from CommonJS instead ofrequire(…). - Stay on the existing version of the package until you can move to ESM.
Faça a requisição de 95 posts, de 20 em 20 posts por request, da URL https://jsonplaceholder.typicode.com/posts, a documentação da paginação está aqui https://github.com/typicode/json-server#paginate. Estas requisições devem ser feitas sequencialmente (só requisita os próximos 20 depois que terminar de requisitar tudo dos 20 anteriores)
Para cada vez que 20 posts forem carregados, carregar todos os comentários de cada um deles de maneira concorrente/paralela (ou seja, requisitar os comentários de todos os 20 posts ao mesmo tempo). Para pegar os comentários de um post você usa a URL https://jsonplaceholder.typicode.com/posts/ID_DO_POST/comments. Isso deve ser feito antes de carregar os próximos 20 posts.
Após carregar todos os posts, carregar os usuários de todos os 95 posts concorrentemente/paralelamente. Para carregar um usuário usa-se a URL https://jsonplaceholder.typicode.com/users/ID_DO_USUARIO. Lembrando que um mesmo usuário pode ter mais de um post, então o mesmo usuário não dev
| https://textio.com/ | |
| http://gender-decoder.katmatfield.com | |
| https://joblint.org/ |
| newtype Reader e a = Reader { runReader :: e -> a } | |
| instance Functor (Reader a) where | |
| fmap f (Reader g) = Reader $ f . g | |
| instance Applicative (Reader a) where | |
| pure x = Reader $ \_ -> x | |
| m <*> n = Reader $ \e -> (runReader m e) (runReader n e) | |
| instance Monad (Reader a) where |
| module FactoryGirl | |
| module Doctor | |
| module FloatDuration | |
| refine Float do | |
| def duration | |
| t = self | |
| format("%02d:%02d.%03d", t / 60, t % 60, t.modulo(1) * 1000) | |
| end | |
| end | |
| end |
| // routes.js | |
| const routes = [ | |
| { | |
| path: '/', | |
| component: Home, | |
| exact: true | |
| }, | |
| { | |
| path: '/gists', | |
| component: Gists |
| /** | |
| * WHY? - BECAUSE EXCEPTIONS/TRY/CATCH IS A GLOBAL HORRIBLE MESS :-( | |
| * Check out error handling in golang: https://blog.golang.org/error-handling-and-go | |
| */ | |
| /** | |
| * Wrap an "unsafe" promise | |
| */ | |
| function safePromise(promise) { | |
| return promise |
