Тоже немного страдаю рисованием (точнее, научением рисованием). Несколько замечаний: 1) Теория третьестепенна против глаза и руки. Обходных путей нет, чтобы научиться рисовать, нужно много рисовать.
2) Очень советую Proko на ютубе. Его откровение про закон Ламберта для отражённого света мне много объяснило в моих ошибках в тоне.
3) Мне нравится, что у вас в рисунках в конце начало появляться движение.
4) И главная ошибка, которой страдаю и я, и вы, судя по примерам рисунков — это пропорции. (соотношение размеров частей в изображении). Попадать в них — одна из скучных, но важных особенностей.
5) Ещё есть Олег Торопыгин на ютубе, весьма токсичный, но для русского уха весьма мотивирующий. Его рассказ в процессе рисования позволяет правильнее понять (и обрубить) в себе типовые ошибки задранного самомнения (когда халтуру сам себе прощаешь, хотя можешь исправить).
Что сразу бросается в глаза, это уникальный понятийный аппарат, практически не пересекающийся как с предметной областью, так и с офисными средствами автоматизации а-ля Excel. Из этого фактора вытекает проблема отсутствия интереса к продукту со стороны потенциальных пользователей, а пользователи — это не ИТ-специалисты банков, а непосредственно сами банкиры.
Следующим фактором неуспеха проекта является отсутствие «политической крыши» в организации, которая могла бы стать потенциальным пользователем системы. Ведь комплексные системы аналитики — это не просто накачанные калькуляторы, а инструмент ведения внутрикорпоративных войн («кто владеет информацией, тот владеет миром»). А потому оппоненты группе, владеющей таким инструментом, всегда будут заинтересованы, чтобы у конкурента не появился эффективный рычаг давления на них самих. При этом сама группа-владелец инструмента всегда будет опасаться попасть в зависимость от технического специалиста, которого потенциально может «перекупить» конкурент. Поэтому в таких проектах нужно абсолютное доверие между «политической крышей» и разработчиком.
Еще один фактор неуспеха связан с отсутствием команды (речь не идет о подчиненных) хотя бы в лице одного специалиста из предметной области, владеющим ИТ на уровне, чтобы в разговоре с ним не нужно было разжевывать элементарные вещи. Потому что в одиночку постоянно приходится переключаться с вопросов предметной области на вопросы ИТ и обратно. Это, во-первых, вызывает потери времени на переключении между темами до половины всего рабочего времени, а во-вторых, у одиночек крайне «узкий канал» генерации идей по сравнению с работой в коллективе, что связано с отсутствием эффективной обратной связи в процессе создания абсолютно нового решения, не имеющего аналогов.
Не уверен, но подозреваю, что в программном коде очень много сгенерированного IDE кода, так как проект довольно долго развивался на Delphi, в котором кодогенерация в свое время преподносилась как супер-фишка. С этим возможно связана переусложненная архитектора, которая с точки зрения разработки крайне тяжело масштабируема.
Подводя итоги, можно сделать вывод о том, что желающих подхватить Ваш проект не будет, можете не рассчитывать. Единственный вариант для запуска проекта — это поиск надежного и комфортного партнера по бизнесу для зарабатывания денег на Вашем продукте. Партнера именно по бизнесу, а не по разработке. Следующим шагом является поиск «политической крыши» из числа первых лиц хотя бы средне-крупной организации (для небольших организаций функционал аналитических систем избыточен). Ну а дальше — как карта ляжет.
На уровне ОС это "починили" следующим образом: они на выходе из сискола сбрасывают ряд кэшей процессора, через которые "утекают" данные, плюс заанмапили полностью kernel address space, а не только защитили от чтения/записи, так что надо теперь восстанавливать/убирать. Процесс этот небыстрый, что ведёт к нескольким дополнительным сотням циклов на каждый сискол. Отсюда просадка производительности на 30% в том же постгресе.
Добавлю. Дабы не навредить себе, минимум. Юридически подкованные сотрудники не многим нужны.
Начиная от авторского вознаграждения за разработанное ПО, до доп. отпуска по учебе.
До банального незнания ТК РФ.
Используйте паттерны, когда понимаете что это нужно.
А для этого нужно понимать принципы и ограничения, которые налагали разработчики на свои проекты десятилетиями дабы добиться от архитектуры необходимых качеств.
Скажем если мы хотим чтобы код легко находился в проекте, повышаем coheasion. Что бы было проще определить насколько модуль кохизив, смотрим на него с точки зрения SRP. Хотим увеличить гибкость и избежать лавинообразных изменений между модулями — нужно снижать coupling, применять dependency inversion и т.д.
Нужно изолировать презентационную логику от логики обработки данных — не вопрос, формируем отдельно слой обработки данных и сверху лепим контроллеры и вьюхи которые будут заниматься отображением готовых данных. Если у нас есть необходимость как-то изолировать обработку данных в отдельном треде, можно попробовать реализовать все таким образом, чтобы один слой лежал в одном треде и только выставлял бы нужное состояние некому view model а в другом слое мы бы отслеживали изменение состояния и перерисовывали вьюху.
Применение же паттернов без осознания принципов и ограничений, которые лежат в их основах, это просто иллюстрация культа Карго.
Короче, я тут отвечал на комменты, дайте сам чонить выскажу.
Когда человек отсчитывает свое мнение от окружающих — собственного мнения у него быть перестает. Такие люди занимаются не собственной жизнью, а угадыванием — какой должна была бы быть его жизнь, чтобы она нравилась окружающим? Ну и переделывают свою жизнь по указке Сообщества.
Но в результате получается не Личность — а всего лишь некая геометрическая сумма личностей окружающих. Не дай бог так жить. Я таких людей называю «Репликантами».
Чтобы жить хорошо, нужно иметь свое собственное мнение, которое основано прежде всего на собственной личности. Таким образом ты оказываешься на порядок сильнее, активней, действенней, эффективней и результативней толпы Репликантов.
В частности, я пишу этот коммент, зная что мне сейчас прилетит минусов. А завтра и в карму можно будет нагадить.
Но это стоит того, потому что быть может кто-нибудь прочитает этот коммент и просветлится.
Хватит сцуко быть геометрической суммой мнений друзей, родственников, мнения из телевизора и учебника. Ты — это ты, и больше ничего! Ты — не твоя машина, ты — не твоя страховка, ты — не твоя квартира.
Будьте собой, товарищи! И тогда ни о какой Самооценке вообще речи не встанет.
Кстати, работодателю можно задавать симметричные вопросы. Есть даже список:
1. Почему вы пригласили на собеседование именно меня?
2. Чем работа в вашей компании выгодно отличается от работы на ваших конкурентов?
3. Какую прибыль приносит вашей компании каждый сотрудник?
4. Почему предыдущий сотрудник, занимавший предлагаемую должность, покинул ее?
5. Каковы планы компании на ближайшие 10 лет?
6. Расскажите о успешных запущенных проектах компании.
7. Расскажите о потенциальном руководителе.
8. Расскажите о конкурентных преимуществах компании?
9. А о проблемах компании? Как компания пережила кризис, были ли сокращения?
В дополнение к списку источников я очень рекомендую книгу Олейникова Р. В.
Построение музыкальных систем. Автор книги закончил кафедру прикладной математики МИФИ, поэтому все объяснения очень понятны для технарей.
В качестве начала делюсь рецептом теста для пиццы, т.к. ее делаю чаще всего ))
1. В 100 мл. теплой воды растворить 0.5 чайной ложки сахара и 1 чайную ложку дрожжей. Оставить на 10 минут.
2. В миску насыпать ~200 гр. муки, около 1/3 чайной ложки соли (по желанию), 1-2 столовых ложки раст. масла (на оливковом тесто получается нежнее). Замесить до однородной массы чуть выше средней плотности.
3. Накрыть в миске тесто влажным полотенцем и оставить на 40 мин.
Активная фаза — минут 15-17.
В качестве соуса очень хорошо подходит «Сацебели» (3-4 столовых ложки). В качестве начинки — что угодно. У меня уходит, половина луковицы (тонко нарезать), около 200 гр мяса (куриное филе, свинина. Сырое), 1 банка черных оливок (порезать оливки пополам), 250 гр. сыра. Печь в духовке на 185-190 град. до готовности. Готовность определяю, когда запах до компьютера дойдет ))) Или, когда тесто хорошо зарумянится.
Да тяжело поспорить с материалом ибо во-первых сам только бакалавр, во-вторых, смотрю на все через линзу MIT, в-третьих, тут многое — дело вкуса.
Из того что заметил:
— у нас первый курс по теме был достаточно тероетический, проводился на scheme и по этой книжке: en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
Выбор scheme был интересен т.к. этому языку мало где учат (что позволяет уравновесить возможности разных студентов) но при этом на нем можно написать очень глубокие вещи — символическую манипуляцию, и тд. Одна из задачек заключалась в том чтобы написать интерпретатор scheme на scheme. Так же scheme использовался для курса по искусственному интеллекту.
Ну эт было давно — в недавнее время со scheme перешли на python и старички начали жаловаться что мол «падает у нас качество и мало мы издеваемся над юнцами».
То есть в принципе — меньше внимания уделяется конкретным языкам (C++ и SQL вообще не упоминаются) но больше теории и практики на конкретных задачах (напиши интерпретатор, напиши компилятор, хоть и на Java, напиши простенькое ядро и тд)…
По базам данных у нас курс только elective — а я, не зная что это мне потом пригодится, так его и не взял. Зато брал криптографию. Вот эт тоже было интересно! Чуть не помер.
Эта книга, похоже, по тематике находится посередине между Хоровиц-Хиллом и Хеннесси-Паттерсоном. Если это действительно так, то это отличные новости! Наконец-то!
Спасибо всем авторам и переводчикам за труд!
На Вашем месте я бы уже читал 2-х томник Хорстманна и Корнелла и подготовил Философию Java Эккеля и Java Эффективное программирование Блоха
Тоже немного страдаю рисованием (точнее, научением рисованием). Несколько замечаний: 1) Теория третьестепенна против глаза и руки. Обходных путей нет, чтобы научиться рисовать, нужно много рисовать.
2) Очень советую Proko на ютубе. Его откровение про закон Ламберта для отражённого света мне много объяснило в моих ошибках в тоне.
3) Мне нравится, что у вас в рисунках в конце начало появляться движение.
4) И главная ошибка, которой страдаю и я, и вы, судя по примерам рисунков — это пропорции. (соотношение размеров частей в изображении). Попадать в них — одна из скучных, но важных особенностей.
5) Ещё есть Олег Торопыгин на ютубе, весьма токсичный, но для русского уха весьма мотивирующий. Его рассказ в процессе рисования позволяет правильнее понять (и обрубить) в себе типовые ошибки задранного самомнения (когда халтуру сам себе прощаешь, хотя можешь исправить).
Следующим фактором неуспеха проекта является отсутствие «политической крыши» в организации, которая могла бы стать потенциальным пользователем системы. Ведь комплексные системы аналитики — это не просто накачанные калькуляторы, а инструмент ведения внутрикорпоративных войн («кто владеет информацией, тот владеет миром»). А потому оппоненты группе, владеющей таким инструментом, всегда будут заинтересованы, чтобы у конкурента не появился эффективный рычаг давления на них самих. При этом сама группа-владелец инструмента всегда будет опасаться попасть в зависимость от технического специалиста, которого потенциально может «перекупить» конкурент. Поэтому в таких проектах нужно абсолютное доверие между «политической крышей» и разработчиком.
Еще один фактор неуспеха связан с отсутствием команды (речь не идет о подчиненных) хотя бы в лице одного специалиста из предметной области, владеющим ИТ на уровне, чтобы в разговоре с ним не нужно было разжевывать элементарные вещи. Потому что в одиночку постоянно приходится переключаться с вопросов предметной области на вопросы ИТ и обратно. Это, во-первых, вызывает потери времени на переключении между темами до половины всего рабочего времени, а во-вторых, у одиночек крайне «узкий канал» генерации идей по сравнению с работой в коллективе, что связано с отсутствием эффективной обратной связи в процессе создания абсолютно нового решения, не имеющего аналогов.
Не уверен, но подозреваю, что в программном коде очень много сгенерированного IDE кода, так как проект довольно долго развивался на Delphi, в котором кодогенерация в свое время преподносилась как супер-фишка. С этим возможно связана переусложненная архитектора, которая с точки зрения разработки крайне тяжело масштабируема.
Подводя итоги, можно сделать вывод о том, что желающих подхватить Ваш проект не будет, можете не рассчитывать. Единственный вариант для запуска проекта — это поиск надежного и комфортного партнера по бизнесу для зарабатывания денег на Вашем продукте. Партнера именно по бизнесу, а не по разработке. Следующим шагом является поиск «политической крыши» из числа первых лиц хотя бы средне-крупной организации (для небольших организаций функционал аналитических систем избыточен). Ну а дальше — как карта ляжет.
На уровне ОС это "починили" следующим образом: они на выходе из сискола сбрасывают ряд кэшей процессора, через которые "утекают" данные, плюс заанмапили полностью kernel address space, а не только защитили от чтения/записи, так что надо теперь восстанавливать/убирать. Процесс этот небыстрый, что ведёт к нескольким дополнительным сотням циклов на каждый сискол. Отсюда просадка производительности на 30% в том же постгресе.
Начиная от авторского вознаграждения за разработанное ПО, до доп. отпуска по учебе.
До банального незнания ТК РФ.
За пять минут в гугле можно найти больше интересных ссылок, чем в этой статье.
Вот, например:
Или вот, из Git репозитория awesome-RemoteWork:
https://whoishiring.io/
https://weworkremotely.com. A page of 37Signals.
http://careers.stackoverflow.com/jobs/remote. Job page of StackOverflow.
http://www.flexjobs.com/jobs/ a service purely focusing on telecommuting, part-time, flexible jobs.
http://www.reddit.com/r/forhire/new/. Subreddit for hiring, not purely a remote job page but have a lots.
http://hnhiring.me/ an aggregator site collects job from HackerNews, easier to read.
http://workinstartups.com/ not all jobs are remote but it has.
https://angel.co/jobs, a lots of startup jobs, set filter for "Remote OK" will show remote jobs.
https://remotecoder.io/
http://www.authenticjobs.com/#onlyremote=1
http://www.remoteyear.com/jobs/, job board of RemoteYear program.
http://nomadjobs.io/
http://jobmote.com/
http://workingnomads.co/
http://www.teamed.io/
http://www.toptal.com
http://automattic.com/work-with-us/. Made https://wordpress.com/, has remote working culture and employees are from everywhere in the world.
https://www.wfh.io/, 100% remote tech-oriented job board
http://jobs.remotive.io/, weekly update with remote jobs from startups.
http://remoteok.io/ a remote job aggregator. Job from Angel List, Stackoverflow,…
http://remotus.com/ a fulltime jobs for developers, still under construction. Seems have a lots of startup jobs.
http://www.candoerz.com/ hourly update remote, relocate, freelance jobs aggregator.
А вот еще из Git репозитория awesome-remote-job:
performedА для этого нужно понимать принципы и ограничения, которые налагали разработчики на свои проекты десятилетиями дабы добиться от архитектуры необходимых качеств.
Скажем если мы хотим чтобы код легко находился в проекте, повышаем coheasion. Что бы было проще определить насколько модуль кохизив, смотрим на него с точки зрения SRP. Хотим увеличить гибкость и избежать лавинообразных изменений между модулями — нужно снижать coupling, применять dependency inversion и т.д.
Нужно изолировать презентационную логику от логики обработки данных — не вопрос, формируем отдельно слой обработки данных и сверху лепим контроллеры и вьюхи которые будут заниматься отображением готовых данных. Если у нас есть необходимость как-то изолировать обработку данных в отдельном треде, можно попробовать реализовать все таким образом, чтобы один слой лежал в одном треде и только выставлял бы нужное состояние некому view model а в другом слое мы бы отслеживали изменение состояния и перерисовывали вьюху.
Применение же паттернов без осознания принципов и ограничений, которые лежат в их основах, это просто иллюстрация культа Карго.
Когда человек отсчитывает свое мнение от окружающих — собственного мнения у него быть перестает. Такие люди занимаются не собственной жизнью, а угадыванием — какой должна была бы быть его жизнь, чтобы она нравилась окружающим? Ну и переделывают свою жизнь по указке Сообщества.
Но в результате получается не Личность — а всего лишь некая геометрическая сумма личностей окружающих. Не дай бог так жить. Я таких людей называю «Репликантами».
Чтобы жить хорошо, нужно иметь свое собственное мнение, которое основано прежде всего на собственной личности. Таким образом ты оказываешься на порядок сильнее, активней, действенней, эффективней и результативней толпы Репликантов.
В частности, я пишу этот коммент, зная что мне сейчас прилетит минусов. А завтра и в карму можно будет нагадить.
Но это стоит того, потому что быть может кто-нибудь прочитает этот коммент и просветлится.
Хватит сцуко быть геометрической суммой мнений друзей, родственников, мнения из телевизора и учебника. Ты — это ты, и больше ничего! Ты — не твоя машина, ты — не твоя страховка, ты — не твоя квартира.
Будьте собой, товарищи! И тогда ни о какой Самооценке вообще речи не встанет.
1. Почему вы пригласили на собеседование именно меня?
2. Чем работа в вашей компании выгодно отличается от работы на ваших конкурентов?
3. Какую прибыль приносит вашей компании каждый сотрудник?
4. Почему предыдущий сотрудник, занимавший предлагаемую должность, покинул ее?
5. Каковы планы компании на ближайшие 10 лет?
6. Расскажите о успешных запущенных проектах компании.
7. Расскажите о потенциальном руководителе.
8. Расскажите о конкурентных преимуществах компании?
9. А о проблемах компании? Как компания пережила кризис, были ли сокращения?
Работа в непрофильной конторе — это всегда борьба жадности с непрофессионализмом.
http://opentracker.dg2.i2p/
http://tracker2.postman.i2p/
Построение музыкальных систем. Автор книги закончил кафедру прикладной математики МИФИ, поэтому все объяснения очень понятны для технарей.
1. В 100 мл. теплой воды растворить 0.5 чайной ложки сахара и 1 чайную ложку дрожжей. Оставить на 10 минут.
2. В миску насыпать ~200 гр. муки, около 1/3 чайной ложки соли (по желанию), 1-2 столовых ложки раст. масла (на оливковом тесто получается нежнее). Замесить до однородной массы чуть выше средней плотности.
3. Накрыть в миске тесто влажным полотенцем и оставить на 40 мин.
Активная фаза — минут 15-17.
В качестве соуса очень хорошо подходит «Сацебели» (3-4 столовых ложки). В качестве начинки — что угодно. У меня уходит, половина луковицы (тонко нарезать), около 200 гр мяса (куриное филе, свинина. Сырое), 1 банка черных оливок (порезать оливки пополам), 250 гр. сыра. Печь в духовке на 185-190 град. до готовности. Готовность определяю, когда запах до компьютера дойдет ))) Или, когда тесто хорошо зарумянится.
Активная фаза в общем — примерно 30-35 минут.
Обзор способов обхода блокировок на «Гиктаймсе»
Рекомендации по обходу блокировок от «РосКомСвободы»
Отдельный вики-сайт по способам обхода блокировок Bloku.net [i2p|b32|tor|cjdns]
Некоторые простые способы преодолеть блокировку запрещенных в России сайтов
Пять простых способов зайти на заблокированные сайты
Да тяжело поспорить с материалом ибо во-первых сам только бакалавр, во-вторых, смотрю на все через линзу MIT, в-третьих, тут многое — дело вкуса.
Из того что заметил:
— у нас первый курс по теме был достаточно тероетический, проводился на scheme и по этой книжке: en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
Выбор scheme был интересен т.к. этому языку мало где учат (что позволяет уравновесить возможности разных студентов) но при этом на нем можно написать очень глубокие вещи — символическую манипуляцию, и тд. Одна из задачек заключалась в том чтобы написать интерпретатор scheme на scheme. Так же scheme использовался для курса по искусственному интеллекту.
Ну эт было давно — в недавнее время со scheme перешли на python и старички начали жаловаться что мол «падает у нас качество и мало мы издеваемся над юнцами».
По алгоритмам вот этот курс очень понравился — он на undergrad уровне но там есть и про b-tree и про randomization чуток:
stellar.mit.edu/S/course/6/sp14/6.046/materials.html
Еще понравился курс computer language engineering: ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-035-computer-language-engineering-spring-2010/lecture-notes/
Тут цель — написать свой собственный компилятор — с оптимизацией и переводом на ассемблер. И это включает в себя обучение ассемблера. И сразу появляется резон выучить эту нечисть.
Вот еще интересный рисунок — как картину обучения видит MIT
www.eecs.mit.edu/docs/ug/6-3.pdf
То есть в принципе — меньше внимания уделяется конкретным языкам (C++ и SQL вообще не упоминаются) но больше теории и практики на конкретных задачах (напиши интерпретатор, напиши компилятор, хоть и на Java, напиши простенькое ядро и тд)…
По базам данных у нас курс только elective — а я, не зная что это мне потом пригодится, так его и не взял. Зато брал криптографию. Вот эт тоже было интересно! Чуть не помер.
Вот так-с… does this help?
Спасибо всем авторам и переводчикам за труд!