Go 1.8 будет выпущен в этом феврале.
Общемировая пати по этому случаю намечена на 16 февраля.
Как изменился Go и к чему пришли:
https://talks.golang.org/2017/state-of-go.slide
В Go 1.8 очень серьёзно поработали над runtime и алгоритмами GC - добились субмиллисекундных задержек на многогигабайтной куче (heap) в памяти!
Это очень ощутимо повысило производительность программ скомпилированных Go 1.8 Release Candidate.
https://twitter.com/brianhatfield/status/804355831080751104
Репозиторий с тестами:
https://github.com/bmhatfield/go-runtime-metrics
Общемировая пати по этому случаю намечена на 16 февраля.
Как изменился Go и к чему пришли:
https://talks.golang.org/2017/state-of-go.slide
В Go 1.8 очень серьёзно поработали над runtime и алгоритмами GC - добились субмиллисекундных задержек на многогигабайтной куче (heap) в памяти!
Это очень ощутимо повысило производительность программ скомпилированных Go 1.8 Release Candidate.
https://twitter.com/brianhatfield/status/804355831080751104
Репозиторий с тестами:
https://github.com/bmhatfield/go-runtime-metrics
Twitter
Brian Hatfield
SUB. MILLISECOND. PAUSE. TIME. ON. AN. 18. GIG. HEAP. (Trying out Go 1.8 beta 1!)
И отличная статья в блоге разработчиков шикарного сервиса Pusher, о том как работает алгоритм GC и как добились мягкого реального времени в GC для Go:
https://blog.pusher.com/golangs-real-time-gc-in-theory-and-practice/
https://blog.pusher.com/golangs-real-time-gc-in-theory-and-practice/
Making Pusher
Golang’s Real-time GC in Theory and Practice - Making Pusher
How Golang's concurrent GC achieves low latencies in real-time systems: a visualization of the algorithm and an empirical comparison with other languages.
Безудержного пятничного веселья пост!
От улыбки станет всем светлей! 😄😂👍
Классный бот, который превратит все ваши grumpy photos в smiley photos.
@MagicSmileBot - просто киньте ему фото и нейросеть заставит улыбнуться и вас и ваше фото
Улыбайтесь чаще друзья! 😁
#thismademyday
#madeit
Many thanks to @Luger_08!
PS:
Нейросетку обучали на наборах данных, парах фото в анфас, где человек улыбается и где не улыбается.
На фото в профиль не обучали, поэтому реконструкция улыбки получается кривая.
Производится именно реконструкция улыбки на лице - нейросеть использует накопленные в тензорных полях данные, шаблоны и отношения между полями, для реконструкции улыбки (губ, зубов, формы, цвета, света-тени/освещения) на конкретном лице и его области.
От улыбки станет всем светлей! 😄😂👍
Классный бот, который превратит все ваши grumpy photos в smiley photos.
@MagicSmileBot - просто киньте ему фото и нейросеть заставит улыбнуться и вас и ваше фото
Улыбайтесь чаще друзья! 😁
#thismademyday
#madeit
Many thanks to @Luger_08!
PS:
Нейросетку обучали на наборах данных, парах фото в анфас, где человек улыбается и где не улыбается.
На фото в профиль не обучали, поэтому реконструкция улыбки получается кривая.
Производится именно реконструкция улыбки на лице - нейросеть использует накопленные в тензорных полях данные, шаблоны и отношения между полями, для реконструкции улыбки (губ, зубов, формы, цвета, света-тени/освещения) на конкретном лице и его области.
DropBox прекращает развитие Pyston, эффективного многопоточного JIT компилятора Python на базе LLVM и полностью передаёт его разработку open-source сообществу.
Чего и следовало ожидать.
Тем более недавно Google опубликовал проект AST транс-компилятора Python в Go - Grumpy (https://github.com/google/grumpy).
Большую часть бэкэнда DropBox уже переписали на Go и Rust с меньшими трудозатратами, что получилось даже быстрее по времени и производительнее по нагрузке.
Go эффективнее Python по исполнению кода.
Оба языка поддерживают FFI - Go через cgo, Python через ctypes.
Но видимо в DropBox не хотели увеличивать количество Си кода в ходе роста нагрузок и выбрали золотую середину - Go.
Хотя от экспертизы Гвидо Ван Россума, как автора языка, автора эталонного интерпретатора и главного специалиста в Python, вроде пока не отказались.
Теперь разработку компилятора Pyston отдали в руки сообщества, которое будет развивать его, что возможно не очень хорошо для проекта потому, что таким образом он будет развиваться не так динамично, как в самой компании - комьюнити проекты JIT компиляторов Python, PyPy и Jython, традиционно не очень активны и развиваются крайне медленно, во многом из-за наличия эталонного CPython и PEP стандартизации нововведений со стороны сообщества. По этой причине все реализации Python кроме эталонной выступают в роли догоняющих проектов.
Но Pyston должен был быть эффективнее PyPy, т.к. использует LLVM в качестве бэкэнд компилятора, который реализует регистровую машину, в отличие от PyPy и CPython, которые реализуют стековую машину (http://doc.pypy.org/en/latest/interpreter.html#introduction-and-overview).
Регистровая машина имеет другую модель памяти - для трансляции байт-кода активно используются регистры и регистровые операции процессора, и соответственно для размещения структур данных используется быстрый процессорный кэш (которого в современных процессорах немало - мегабайты).
Поэтому регистровая машина работает быстрее и лучше подходит для языка Python и реализации всех его концепций (сопрограмм, итераторов, генераторов), как языка с динамической системой типов, для реализации в байт-коде более быстрого динамического определения типов объектов в runtime через dynamic dispatch (динамическую диспетчеризацию типов).
Более того выделение памяти в кэше процессора ускоряет обмен данными и работу с ними, и позволяет разместить в нём кучу (binary heap, которая обычно размещается в намного более медленной RAM), содержащую кадры стека вызовов сопрограмм (parent pointer tree with cactus stack), для более быстрой работы с ней, что в свою очередь нивелирует проблему funarg (как восходящего, так и нисходящего funarg) для сопрограмм - проблему сложности быстрой работы на низком уровне с более комплексными структурами данных типа дерева, хранящими стэки вызова сопрограм и подпрограмм, из-за отсутствия широкой поддержки таких структур данных машинной архитектурой для их размещения в более быстрой памяти.
Поэтому регистровая машина (LLVM) эффективна для реализации сопрограмм и многопоточности по модели CSP, основанной на их использовании, таким образом Pyston имеет реализацию многопоточности, не ограниченную GIL, которая базируется на сопрограммах и их асинхронных вызовах (async/await).
https://github.com/dropbox/pyston
https://blog.pyston.org
http://speed.pyston.org/comparison/
https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/
Чего и следовало ожидать.
Тем более недавно Google опубликовал проект AST транс-компилятора Python в Go - Grumpy (https://github.com/google/grumpy).
Большую часть бэкэнда DropBox уже переписали на Go и Rust с меньшими трудозатратами, что получилось даже быстрее по времени и производительнее по нагрузке.
Проанализировав состояние проекта компания пришла к выводу, что на поддержание совместимости с CPython и обеспечение приемлемого потребления памяти требуется значительно больше ресурсов и затрат, чем ожидалось. Но решающим фактором отказа от проекта Pyston стали не оправдавшиеся завышенные надежды на производительность Pyston.
Go эффективнее Python по исполнению кода.
Оба языка поддерживают FFI - Go через cgo, Python через ctypes.
Но видимо в DropBox не хотели увеличивать количество Си кода в ходе роста нагрузок и выбрали золотую середину - Go.
Хотя от экспертизы Гвидо Ван Россума, как автора языка, автора эталонного интерпретатора и главного специалиста в Python, вроде пока не отказались.
Теперь разработку компилятора Pyston отдали в руки сообщества, которое будет развивать его, что возможно не очень хорошо для проекта потому, что таким образом он будет развиваться не так динамично, как в самой компании - комьюнити проекты JIT компиляторов Python, PyPy и Jython, традиционно не очень активны и развиваются крайне медленно, во многом из-за наличия эталонного CPython и PEP стандартизации нововведений со стороны сообщества. По этой причине все реализации Python кроме эталонной выступают в роли догоняющих проектов.
Но Pyston должен был быть эффективнее PyPy, т.к. использует LLVM в качестве бэкэнд компилятора, который реализует регистровую машину, в отличие от PyPy и CPython, которые реализуют стековую машину (http://doc.pypy.org/en/latest/interpreter.html#introduction-and-overview).
Регистровая машина имеет другую модель памяти - для трансляции байт-кода активно используются регистры и регистровые операции процессора, и соответственно для размещения структур данных используется быстрый процессорный кэш (которого в современных процессорах немало - мегабайты).
Поэтому регистровая машина работает быстрее и лучше подходит для языка Python и реализации всех его концепций (сопрограмм, итераторов, генераторов), как языка с динамической системой типов, для реализации в байт-коде более быстрого динамического определения типов объектов в runtime через dynamic dispatch (динамическую диспетчеризацию типов).
Более того выделение памяти в кэше процессора ускоряет обмен данными и работу с ними, и позволяет разместить в нём кучу (binary heap, которая обычно размещается в намного более медленной RAM), содержащую кадры стека вызовов сопрограмм (parent pointer tree with cactus stack), для более быстрой работы с ней, что в свою очередь нивелирует проблему funarg (как восходящего, так и нисходящего funarg) для сопрограмм - проблему сложности быстрой работы на низком уровне с более комплексными структурами данных типа дерева, хранящими стэки вызова сопрограм и подпрограмм, из-за отсутствия широкой поддержки таких структур данных машинной архитектурой для их размещения в более быстрой памяти.
Поэтому регистровая машина (LLVM) эффективна для реализации сопрограмм и многопоточности по модели CSP, основанной на их использовании, таким образом Pyston имеет реализацию многопоточности, не ограниченную GIL, которая базируется на сопрограммах и их асинхронных вызовах (async/await).
https://github.com/dropbox/pyston
https://blog.pyston.org
http://speed.pyston.org/comparison/
https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/
www.opennet.ru
Dropbox прекращает разработку Pyston. Опубликован финальный выпуск 0.6.1
Опубликовано обновление проекта Pyston 0.6.1, в рамках которого компанией Dropbox развивалась высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM и использующая JIT-компиляцию для достижения высокой производительности.…
Technologique
Что касается Python... У Python область применения намного более узкая из-за динамической типизации и интерпретации, которая фактически является единственным вариантом среды исполнения промежуточного байт-кода эталонного CPython, в инструкции которого заключены…
Ранее, выше я уже писал о непростой судьбе интерпретируемых языков Python, Ruby и сложности реализации эффективных JIT компиляторов для этих языков, что ограничивает их развитие и применение, во многом из их динамической природы и концепций, основанных на динамизме типов данных.
Сложности в дальнейшем развитии проекта Pyston это лишний раз подтверждают.
Сложности в дальнейшем развитии проекта Pyston это лишний раз подтверждают.
Представьте себе работу программы в многопоточном режиме...
Выделяется кадр стека, в который сохраняется контекст вызова функции, для переключения на код другой функции, в этом же или другом потоке, и для получения контекста для неё.
Это называется переключением контекста вызова для процессора в многозадачном режиме ядром ОС.
Контекст это память, которая содержит состояние регистров процессора, переменные области видимости функции, переданные ей параметры (аргументы функции)...
Переданный параметр может быть указателем на код функции и тогда это first class function, и если это указатель на вложенную функцию, которая возвращает данные в эту же функцию, то это closure/замыкание.
Либо параметр может иметь указатель на код функции, возвращающей другой кадр стэка и соответственно контекст в эту же функцию, или даже вызывать другую функцию, возвращая ей этот контекст, которая в свою очередь уже возвращает стэк/контекст вызова или уже финальные данные в эту начальную функцию.
Такая передача контекстов через параметры функций называется continuation passing style, а передающие контекст функции называются продолжениями (continuations).
Таким образом происходит вызов функций по цепочке с сохранением контекста каждого вызова.
В цепочку вызовов функций (рутин, routine) с сохранением контекста раскладываются вложенные и рекурсивные вызовы функций и вызовы сопрограмм (корутин, coroutine).
Это и происходит на низком уровне при вызове сопрограмм - итераторов, генераторов, горутин, файберов, потоков/нитей, etc., т.е. многопоточных и асинхронных высокоуровневых конструкций, которые переводятся в итоге на низком уровне в сопрограммы.
Это увеличивает сложность компилятора, потому что требуется отследить все вызовы, чтобы выстроить всю цепочку вызовов и отследить время существания всех кадров стэка и контекстов вызова для последующего освобождения памяти.
Сложность рекурсивного вызова выше чем вложенного.
Рекурсивный циклический вызов может быть бесконечным и его цепочку отследить сложнее.
Для этого компилятор должен уметь выполнять оптимизацию циклов и оптимизацию хвостовой рекурсии (tail recursion optimization), т.е. оптимизацию вызовов при возврате из одной функции и передаче контекста вызова в другую.
В итоге стэк может быть переполнен, т.к. заранее неизвестно сколько памяти нужно выделить под стэк, потому что неизвестно сколько циклов вызовов будет прежде, чем произойдёт возврат данных в начальную функцию, т.е. количество вызовов и длина всей цепочки вызовов изначально неизвестна компилятору.
Также учитывая многосвязность вызовов через указатели и кадров стэка, хранящих контекст вызова, очевидно, что структура данных типа стэк (буфер first-in last-out) уже не подходит для хранения контекста всех вызовов, т.к. такая многосвязность множественных кадров стэка через указатели порождает структуру данных cactus stack (parent pointer tree) типа in-tree дерево или многосвязный граф, для хранения которого используется структура данных типа куча (binary heap), под которую происходит динамическое выделение памяти ядром ОС уже в более медленной основной RAM, тогда как для выделения стэка, благодаря его заранее известному и ограниченному размеру, используются регистры процессора и более быстрая регистровая кэш память процессора.
Плюс структура данных типа стэк, благодаря своей упорядоченности, проще и быстрее в работе, обработке и обращении с ней
Это и есть проблема funarg, аргументов/параметров функций, которая сводится в итоге к фундаментальным ограничениям машинной архитектуры и задержкам динамической оперативной памяти.
#сложновато
Выделяется кадр стека, в который сохраняется контекст вызова функции, для переключения на код другой функции, в этом же или другом потоке, и для получения контекста для неё.
Это называется переключением контекста вызова для процессора в многозадачном режиме ядром ОС.
Контекст это память, которая содержит состояние регистров процессора, переменные области видимости функции, переданные ей параметры (аргументы функции)...
Переданный параметр может быть указателем на код функции и тогда это first class function, и если это указатель на вложенную функцию, которая возвращает данные в эту же функцию, то это closure/замыкание.
Либо параметр может иметь указатель на код функции, возвращающей другой кадр стэка и соответственно контекст в эту же функцию, или даже вызывать другую функцию, возвращая ей этот контекст, которая в свою очередь уже возвращает стэк/контекст вызова или уже финальные данные в эту начальную функцию.
Такая передача контекстов через параметры функций называется continuation passing style, а передающие контекст функции называются продолжениями (continuations).
Таким образом происходит вызов функций по цепочке с сохранением контекста каждого вызова.
В цепочку вызовов функций (рутин, routine) с сохранением контекста раскладываются вложенные и рекурсивные вызовы функций и вызовы сопрограмм (корутин, coroutine).
Это и происходит на низком уровне при вызове сопрограмм - итераторов, генераторов, горутин, файберов, потоков/нитей, etc., т.е. многопоточных и асинхронных высокоуровневых конструкций, которые переводятся в итоге на низком уровне в сопрограммы.
Это увеличивает сложность компилятора, потому что требуется отследить все вызовы, чтобы выстроить всю цепочку вызовов и отследить время существания всех кадров стэка и контекстов вызова для последующего освобождения памяти.
Сложность рекурсивного вызова выше чем вложенного.
Рекурсивный циклический вызов может быть бесконечным и его цепочку отследить сложнее.
Для этого компилятор должен уметь выполнять оптимизацию циклов и оптимизацию хвостовой рекурсии (tail recursion optimization), т.е. оптимизацию вызовов при возврате из одной функции и передаче контекста вызова в другую.
В итоге стэк может быть переполнен, т.к. заранее неизвестно сколько памяти нужно выделить под стэк, потому что неизвестно сколько циклов вызовов будет прежде, чем произойдёт возврат данных в начальную функцию, т.е. количество вызовов и длина всей цепочки вызовов изначально неизвестна компилятору.
Также учитывая многосвязность вызовов через указатели и кадров стэка, хранящих контекст вызова, очевидно, что структура данных типа стэк (буфер first-in last-out) уже не подходит для хранения контекста всех вызовов, т.к. такая многосвязность множественных кадров стэка через указатели порождает структуру данных cactus stack (parent pointer tree) типа in-tree дерево или многосвязный граф, для хранения которого используется структура данных типа куча (binary heap), под которую происходит динамическое выделение памяти ядром ОС уже в более медленной основной RAM, тогда как для выделения стэка, благодаря его заранее известному и ограниченному размеру, используются регистры процессора и более быстрая регистровая кэш память процессора.
Плюс структура данных типа стэк, благодаря своей упорядоченности, проще и быстрее в работе, обработке и обращении с ней
Это и есть проблема funarg, аргументов/параметров функций, которая сводится в итоге к фундаментальным ограничениям машинной архитектуры и задержкам динамической оперативной памяти.
#сложновато
Evan Shaw в интервью весьма верно отметил, что компилятор Go и его GC достаточно умно спроектированы, чтобы в зависимости от ситуации выбрать размещение контекста гоурутин и функций в стэке или в куче и грядущий релиз Go 1.8 с субмиллисекундными! задержками работы GC с памятью прекрасно это доказывает. (1)
При каждом обращении к куче увеличиваются задержки из-за её размещения в более медленной RAM памяти.
Задержка может происходить при размещении контекста вызова в куче либо при извлечении контекста вызова из неё, отсюда различают проблему восходящих и низходящих аргументов/параметров функций (funarg).
Недавно нашёл толковое и простое определение проблемы funarg:
Nested functions may in certain situations (and languages) lead to the creation of a closure. If it is possible for the nested function to escape the enclosing function, for example if functions are first class objects and a nested function is passed to another function or returned from the enclosing function, then a closure is created and calls to this function can access the environment of the original function. The frame of the immediately enclosing function must continue to be alive until the last referencing closure dies and non-local automatic variables referenced in closures can therefore not be stack allocated. This is known as the funarg problem and is a key reason why nested functions was not implemented in some simpler languages as it significantly complicates code generation and analysis, especially when functions are nested to various levels, sharing different parts of their environment.
Funarg problem
Continuation
Continuation-passing style (CPS)
Call with current continuation (call/cc)
Parent pointer tree
При каждом обращении к куче увеличиваются задержки из-за её размещения в более медленной RAM памяти.
Задержка может происходить при размещении контекста вызова в куче либо при извлечении контекста вызова из неё, отсюда различают проблему восходящих и низходящих аргументов/параметров функций (funarg).
Недавно нашёл толковое и простое определение проблемы funarg:
Nested functions may in certain situations (and languages) lead to the creation of a closure. If it is possible for the nested function to escape the enclosing function, for example if functions are first class objects and a nested function is passed to another function or returned from the enclosing function, then a closure is created and calls to this function can access the environment of the original function. The frame of the immediately enclosing function must continue to be alive until the last referencing closure dies and non-local automatic variables referenced in closures can therefore not be stack allocated. This is known as the funarg problem and is a key reason why nested functions was not implemented in some simpler languages as it significantly complicates code generation and analysis, especially when functions are nested to various levels, sharing different parts of their environment.
Funarg problem
Continuation
Continuation-passing style (CPS)
Call with current continuation (call/cc)
Parent pointer tree
Telegram
Technologique
Интервью с ответами на вопросы (https://docs.google.com/spreadsheets/d/1bieE_mFwAflhsxXCjasLqKJIq3ilUEUWcwI4CE9hEqU/) по Golang с разработчиками Iron.io, применяющими Go в продакшене - Романом Кононовым (@rkononov) и Эваном Шоу (Evan Shaw), автором книг по…
Technologique
Представьте себе работу программы в многопоточном режиме... Выделяется кадр стека, в который сохраняется контекст вызова функции, для переключения на код другой функции, в этом же или другом потоке, и для получения контекста для неё. Это называется переключением…
This media is not supported in your browser
VIEW IN TELEGRAM
Основной репозиторий Python и разработку эталонного интерпретатора CPython полностью перенесли на Git и хостинг проектов GitHub.
Решение было принято 1 января 2017 года, однако обсуждение предложения о миграции кодовой базы проекта происходило с ноября 2014 года.
Ранее в 2009 году разработка была переведена с репозитория Subversion на систему управления версиями Mercurial, которая в свою очередь реализована на языке Python.
Тесты производительности и эффективности хранения регулярно показывают превосходство Git над другими распределенными системами управления исходными текстами, Mercurial и Bazaar.
Перенос основного репозитория Python на GitHub также поможет вовлечь большую аудиторию в разработку CPython.
Решение было принято 1 января 2017 года, однако обсуждение предложения о миграции кодовой базы проекта происходило с ноября 2014 года.
Ранее в 2009 году разработка была переведена с репозитория Subversion на систему управления версиями Mercurial, которая в свою очередь реализована на языке Python.
Тесты производительности и эффективности хранения регулярно показывают превосходство Git над другими распределенными системами управления исходными текстами, Mercurial и Bazaar.
Перенос основного репозитория Python на GitHub также поможет вовлечь большую аудиторию в разработку CPython.
www.opennet.ru
Разработка Python переведена на GitHub
Разработчики языка программирования Python сообщили об успешном завершении миграции первичного репозитория исходных текстов CPython на сервис GitHub, который отныне будет выступать в качестве основной площадки для разработки. Руководство для разработчиков…
Forwarded from N + 1
Началась прямая трансляция запуска тяжелой ракеты-носителя Ariane 5 с космодрома Куру. Ракета должна доставить на геопереходную орбиту телекоммуникационные спутники SKY Brasil-1 и Telkom 3S.
Старт запланирован на 00:39 по московскому времени
http://www.arianespace.com/mission/ariane-flight-va235/
Старт запланирован на 00:39 по московскому времени
http://www.arianespace.com/mission/ariane-flight-va235/
Forwarded from Brodetskyi. Tech, VC, Startups
Красивая визуализация того, как распространяется "синапс" между "нейронами" разных слоёв нейросети во время её обучения. Разноцветные многоуровневые графы с миллионами вершин и связей, очень красиво. Если вы что-нибудь слышали про слои, нейроны и обучение нейросетей, смотреть эти картинки ещё интереснее. И тем более читать описания 🤓
http://www.wired.co.uk/gallery/machine-learning-graphcore-pictures-inside-ai
Здесь ещё картинки и больше текста:
https://www.graphcore.ai/blog/what-does-machine-learning-look-like
http://www.wired.co.uk/gallery/machine-learning-graphcore-pictures-inside-ai
Здесь ещё картинки и больше текста:
https://www.graphcore.ai/blog/what-does-machine-learning-look-like
В мессенджере Signal, с упором на приватность и безопасность обмена информацией, сделали видеозвонки
https://whispersystems.org/blog/signal-video-calls-beta/
https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms
Ждём приватных аудио и видеозвонков с потоковым шифрованием в Telegram.
https://whispersystems.org/blog/signal-video-calls-beta/
https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms
Ждём приватных аудио и видеозвонков с потоковым шифрованием в Telegram.
Signal
Video calls for Signal now in public beta
Today’s Signal release for Android and iOS includes beta support for video calls. This represents an entirely new calling infrastructure for Signal, and should increase voice call quality as well. We think it’s a big improvement, but we’re rolling it out…
Трансляция TensorFlow Developer Summit 2017
Live Stream:
https://youtu.be/LqLyrl-agOw
https://events.withgoogle.com/tensorflow-dev-summit/
Сегодня состоялся релиз версии 1.0 библиотеки для глубокого машинного обучения TensorFlow:
https://github.com/tensorflow/tensorflow/releases/tag/v1.0.0
#tfdevsummit
#tensorflow
Live Stream:
https://youtu.be/LqLyrl-agOw
https://events.withgoogle.com/tensorflow-dev-summit/
Сегодня состоялся релиз версии 1.0 библиотеки для глубокого машинного обучения TensorFlow:
https://github.com/tensorflow/tensorflow/releases/tag/v1.0.0
#tfdevsummit
#tensorflow
YouTube
TensorFlow Dev Summit 2017 - Livestream
The livestream will start at 9:30am Pacific Time on February 15th, 2017. Join the TensorFlow team and machine learning experts from around the world for a fu...
Technologique
Трансляция TensorFlow Developer Summit 2017 Live Stream: https://youtu.be/LqLyrl-agOw https://events.withgoogle.com/tensorflow-dev-summit/ Сегодня состоялся релиз версии 1.0 библиотеки для глубокого машинного обучения TensorFlow: https://github.com/te…
Плэйлист с нарезкой видео из вчерашней трансляции TensorFlow Developer Summit 2017
https://www.youtube.com/playlist?list=PLOU2XLYxmsIKGc_NBoIhTn2Qhraji53cv
https://www.youtube.com/playlist?list=PLOU2XLYxmsIKGc_NBoIhTn2Qhraji53cv
Две самые годные книги по шаблонам проектирования, которые применимы не только для JavaScript:
Стоян Стефанов, JavaScript - Шаблоны проектирования
Эдди Османи, Learning JavaScript Design Patterns
После прочтения этих книг могу только одно сказать - не будьте пленниками шаблонного мышления! Каждый проект уникален по своему! Изучайте архитектурные парадигмы и концепции языков! Процессы тестирования и обеспечение качества! Это самый верный способ писать лучший код!
#books
Стоян Стефанов, JavaScript - Шаблоны проектирования
Эдди Османи, Learning JavaScript Design Patterns
После прочтения этих книг могу только одно сказать - не будьте пленниками шаблонного мышления! Каждый проект уникален по своему! Изучайте архитектурные парадигмы и концепции языков! Процессы тестирования и обеспечение качества! Это самый верный способ писать лучший код!
#books
Addyosmani
Learning JavaScript Design Patterns
An open-source book on JavaScript Design Patterns