Now you can just install Liberica JDK pkg-distibution using brew
and will never face the problem mentioned below:
brew tap bell-sw/liberica
brew cask install liberica-jdk11
L1 | |
Базовые знание диалекта Typescript, основных встроенных примитивов (Array, Object, Function, String, Date) и методов работы с ними, понимание контекста (this) и способов управления им | |
Базовые знания фреймворка React | |
Знание наиболее часто используемых Web API: fetch/XHR, Storage, PostMessage, DOM | |
Умение писать простейшие алгоритмы (поиск, сортировка, сравнение объектов) без требований к их оптимальности. | |
Навыки кроссбраузерной адаптивной верстки по макету с использованием существующего кода, знание CSS и препроцессора SCSS | |
Навыки отладки разметки в браузерах Chrome/Safari | |
Знание принципов работы HTTP, отличий между различными методами, принципов работы Cookies | |
Практическое владение лучшими практиками структурирования кода: SOLID/DRY/KISS и т.д. | |
Базовые знания git, понимание git flow |
#!/usr/bin/env bash | |
set -Eeuo pipefail | |
trap cleanup SIGINT SIGTERM ERR EXIT | |
script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P) | |
usage() { | |
cat <<EOF | |
Usage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...] |
apk-tools 2.8.2, compiled for x86_64.
usage: apk COMMAND [-h|--help] [-p|--root DIR] [-X|--repository REPO] [-q|--quiet] [-v|--verbose] [-i|--interactive] [-V|--version] [-f|--force]
[--force-binary-stdout] [--force-broken-world] [--force-non-repository] [--force-old-apk] [--force-overwrite] [--force-refresh] [-U|--update-cache]
[--progress] [--progress-fd FD] [--no-progress] [--purge] [--allow-untrusted] [--wait TIME] [--keys-dir KEYSDIR] [--repositories-file REPOFILE]
[--no-network] [--no-cache] [--cache-dir CACHEDIR] [--arch ARCH] [--print-arch] [ARGS]...
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
For a project I am on I need to use a key-value store to converts file-paths to fixnum IDs. The dataset will typically be in the range of 100 000 to 1 000 000. These tests use 305 000 file paths to fixnum IDs.
The Different Key-Value stores tested are:
Daybreak: "Daybreak is a simple and very fast key value store for ruby" GDBM: GNU dbm. "a simple database engine for storing key-value pairs on disk." DBM: "The DBM class provides a wrapper to a Unix-style dbm or Database Manager library" PStore: "PStore implements a file based persistence mechanism based on a Hash. "
Out of these, all except Daybreak are in the Ruby standard library.
You appear to be advocating a new: | |
[ ] cloud-hosted [ ] locally installable [ ] web-based [ ] browser-based [ ] language-agnostic | |
[ ] language-specific IDE. Your IDE will not succeed. Here is why it will not succeed. | |
You appear to believe that: | |
[ ] Syntax highlighting is what makes programming difficult | |
[ ] Garbage collection is free | |
[ ] Computers have infinite memory | |
[ ] Nobody really needs: |
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at the University of Augsburg currently in the fourth year of my studies. I first came to django shortly before 0.96 was released and a lots of awesomeness was introduced with the magic removal branch.
I'm also doing some django freelancing work since 2008 to finance my studies and attended DjangoCon EU in 2010. This year I would like to apply to