Forwarded from DIGITAL XYИGITAL
подготовили пресс-релиз для тупеньких, чтобы ты с тренда не сплыл ненароком
PostgreSQL
Решил поделиться радостью использования PostgreSQL. Постгрес просто песня - он бесплатный, мощный, быстрый, имеет подробнейшую документацию. Ну и как же удобно пользоваться Постгресом после любой другой субд. Работа с датами вообще отдельный кайф:
Округлить время до даты
Округлить время до месяца
Получить вчерашнюю дату
Группировка количества новых пользователей по дням
2019-12-22 00:00:00.000000 8235
#PostgreSQL #db
Решил поделиться радостью использования PostgreSQL. Постгрес просто песня - он бесплатный, мощный, быстрый, имеет подробнейшую документацию. Ну и как же удобно пользоваться Постгресом после любой другой субд. Работа с датами вообще отдельный кайф:
Округлить время до даты
(timestamp '2020-06-12 20:11')::date;
2020-06-12Округлить время до месяца
date_trunc('month', timestamp '2020-06-12 20:11');
2020-06-01 00:00:00Получить вчерашнюю дату
NOW() - INTERVAL '1 DAY’;
2019-12-22 22:01:20.169710Группировка количества новых пользователей по дням
date_trunc('day', date_add),
count(1)
from client
group by 1;
2019-12-23 00:00:00.000000 332019-12-22 00:00:00.000000 8235
#PostgreSQL #db
Как установить PostgreSQL
На мак постгря ставится одной командой
Дальше всё тоже красиво.
Создать базу
Создать пользователя
Дать права пользователю
Подключиться к базе
Выход
#PostgreSQL #db
На мак постгря ставится одной командой
brew install postgresql
Дальше всё тоже красиво.
Создать базу
postgres=# CREATE DATABASE DB_NAME;
Создать пользователя
postgres=# CREATE USER USER_NAME WITH password ‘pass’;
Дать права пользователю
postgres=# GRANT ALL ON DATABASE DB_NAME TO USER_NAME;
Подключиться к базе
postgres=# \c DB_NAME
Выход
DB_NAME=# \q
Источник: https://900913.ru/note/b/postgresql-macos-9da176/#PostgreSQL #db
Пока готовил посты, наткнулся на статью «Курс молодого бойца PostgreSQL»
habr.com/ru/post/340460/
habr.com/ru/post/340460/
Друган Вован говорит, что не хватает инфы для хардкорных девов. Ну и накинул от себя, чем PostgreSQL хорош
15 плюсов PostgreSQL
1. Бесплатный, шустрый и очень распространенный
2. Для него куча документаций, книг, туториалов, статей, уроков
3. Установить в линуксе можно одной командой без дрочки с настройкой
4. В нем есть postgis, fts, jsonb, gin/gist. В новых версиях завозят приятный сахар
5. Материализованные вьюхи, обновление строк через обновление вьюх, fdw тоже норм
6. Покрывающие индексы, функциональные индексы
7. В нем есть? наверное всё, что есть в платных бд
8. Под него написано куча всего - адаптеров, расширений, приложений (балансировщики, репликаторы), поддерживается средствами разработки
9. В нем есть мощные оконные и прочие функции. Параллелизируемость запросов
10. Один из самых крутых опенсорс проектов. В него влито нереально большое количество сил кучи контрибьюторов. 20 лет назад никто не мог подумать, что PostgreSQL станет топовой СУБД и не будет уступать дорогущим проприетарным базам
11. И в постгресе лучше MVCC сделано, чем в оракл
12. А еще язык pg/plsql просто бомба
13. Ну и в нём можно свои типы объявлять
14. Постгря разрешает группировать по любому выражению, а не только по имеющимся колонкам
15. Одной рукой пишу запрос, второй рукой слезу счастья вытираю
1. Бесплатный, шустрый и очень распространенный
2. Для него куча документаций, книг, туториалов, статей, уроков
3. Установить в линуксе можно одной командой без дрочки с настройкой
4. В нем есть postgis, fts, jsonb, gin/gist. В новых версиях завозят приятный сахар
5. Материализованные вьюхи, обновление строк через обновление вьюх, fdw тоже норм
6. Покрывающие индексы, функциональные индексы
7. В нем есть? наверное всё, что есть в платных бд
8. Под него написано куча всего - адаптеров, расширений, приложений (балансировщики, репликаторы), поддерживается средствами разработки
9. В нем есть мощные оконные и прочие функции. Параллелизируемость запросов
10. Один из самых крутых опенсорс проектов. В него влито нереально большое количество сил кучи контрибьюторов. 20 лет назад никто не мог подумать, что PostgreSQL станет топовой СУБД и не будет уступать дорогущим проприетарным базам
11. И в постгресе лучше MVCC сделано, чем в оракл
12. А еще язык pg/plsql просто бомба
13. Ну и в нём можно свои типы объявлять
14. Постгря разрешает группировать по любому выражению, а не только по имеющимся колонкам
15. Одной рукой пишу запрос, второй рукой слезу счастья вытираю
Какую БД используете чаще всего?
Anonymous Poll
43%
PostgreSQL
21%
MySQL/MariaDB
11%
MS SQL
17%
Oracle
8%
NoSQL
Запускаем PostgreSQL в докере
Стягиваем образ с докер хаба
Создаём папку, куда постгря будет складывать данные
Запускаем контейнер
При первом запуске он скачает с докер хаба образ, а потом за секунду стартует. Запуск контейнера просит sudo права. Плюс надо заранее поставить пакет docker.io. Так можно одновременно держать несколько версий постгре рядом без дикой боли.
Источник: https://hackernoon.com/dont-install-postgres-docker-pull-postgres-bee20e200198
Стягиваем образ с докер хаба
pull postgres
Создаём папку, куда постгря будет складывать данные
-p $HOME/docker/volumes/postgres
Запускаем контейнер
run --rm --name pg-docker -e POSTGRES_PASSWORD=docker -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data postgres
-rm
— удаляем контейнер после выхода-name
— задаём имя контейнеру-e
— задаём переменные окружения: имя базы, пользователя, пароль-d
— запускаем контейнер фоном-p
— прокидываем порт наружу-v
— монтируем созданную ранее папку по адресу, который постгре использует по-дефолтуПри первом запуске он скачает с докер хаба образ, а потом за секунду стартует. Запуск контейнера просит sudo права. Плюс надо заранее поставить пакет docker.io. Так можно одновременно держать несколько версий постгре рядом без дикой боли.
Источник: https://hackernoon.com/dont-install-postgres-docker-pull-postgres-bee20e200198
Интервью с head of mobile Яндекс.Транспорта
На мероприятии от подкаста Подлодка познакомился с Женей Кателла. Узнал, что он не только ведёт подкаст и работает в Яндексе, но ещё добрый открытый парень, который работал раньше джавистом на бэке. Тут я понял, что о переходе из бэка в мобилки стоит расспросить поподробнее.
И благодаря Жениной открытости получилось объёмное интервью. Он рассказал, чем мобилки круче бека, как развиваться разработчику, как устроен процесс разработки в Яндексе и многое другое. Я разделил интервью на части и самый сок выложу сюда, в канал. Полную версию отредактирую и залью позже на Хабр или VC.
Читайте, наслаждайтесь, ставьте классы.
#интервью #Яндекс #mobile
На мероприятии от подкаста Подлодка познакомился с Женей Кателла. Узнал, что он не только ведёт подкаст и работает в Яндексе, но ещё добрый открытый парень, который работал раньше джавистом на бэке. Тут я понял, что о переходе из бэка в мобилки стоит расспросить поподробнее.
И благодаря Жениной открытости получилось объёмное интервью. Он рассказал, чем мобилки круче бека, как развиваться разработчику, как устроен процесс разработки в Яндексе и многое другое. Я разделил интервью на части и самый сок выложу сюда, в канал. Полную версию отредактирую и залью позже на Хабр или VC.
Читайте, наслаждайтесь, ставьте классы.
#интервью #Яндекс #mobile
— как ты попал в айти?
Тут история в трех актах. Хотелось бы рассказать вдохновляющую историю о том, как я что-то сложное запрограммировал в 10 лет, но нет. Началось все, когда мне было лет 6 – с компьютерных игр. Позднее иногда баловался с MS Paint, Powerpoint (почему-то мне это казалось интересным), Corel Draw. Но это случалось редко и бессистемно. Большую часть времени я играл. И все это время в голове сидело чувство, что это все, конечно, хорошо, но было бы круто научиться делать с помощью компьютера что-то полезное и «серьезное».
В 9 классе я увидел у старшего брата книгу по Turbo Pascal для студентов-первокурсников и неожиданно заинтересовался программированием. Я перешел из своей школы в лицей информационных технологий, а оттуда осознанно поступил в универ на специальность «Информационные системы и технологии». Я не до конца понимал, чем хочу заниматься, т.к. я очень плохо представлял продакшен-разработку. Но знал, что хочется работать в сфере, связанной с компьютерами.
Ну и последний, третий акт начался на втором курсе, когда я первый раз в жизни пошел по-настоящему работать. На втором курсе я подрабатывал эникейщиком в универе: научился настраивать, обслуживать и диагностировать компьютеры. На 4 курсе пошел работать на полставки в крупную госкомпанию в службу эксплуатации. Там еще удалось немного влезть в настройку сетей, сетевого оборудования и т.д.
К моменту выпуска из универа у меня был какой-то админский опыт с сетями и серверами, базовые знания программирования, но я не понимал до конца, чем хочу заниматься и не знал, как устроена разработка в «реальном» мире. Потом случайно узнал, что есть вакансия инженера-программиста в отделении РАН. Так я попал одновременно и в науку, и в какое-никакое программирование. Я писал на C# софтину для операторов крупного предприятия. Никакого rocket-science, но было интересно, хотя сейчас я понимаю, что наши поделки недалеко ушли от уровня универских лабораторных. К сожалению, не было рядом скиллового программиста, у которого можно было бы поучиться. Параллельно с основной работой я влез во фриланс-проект на PHP, где первый раз самостоятельно взаимодействовал с заказчиком.
— как получилось, что ты работал в Хабаровске бэкендером, а теперь хэд мобильной разработки в Яндексе?
Череда случайностей 🙂 Я работал java-бэкендером в Хабаровской компании, а в свободное время делал парочку фриланс-проектов под Android. Было интересно изучать что-то новое и обкатывать привычные подходы из бэкенда на андроиде. Потом в компании произошел ряд изменений, большинство стоящих сотрудников уволились. Я не стал исключением и начал собеседоваться везде, где только можно. В Хабаровске идти было некуда, поэтому я рассматривал релокацию в Москву или Питер. Изначально целился на бэкенд, но было интересно попробовать себя и в «серьезной» мобильной разработке. В итоге у меня было два оффера в Москву. Один на бэкенд в неизвестную мне на тот момент компанию, второй – на мобилку в Rambler. Рамблер был больше на слуху и условия предложили получше. Так я стал мобильным разработчиком. Ну а дальше типичная карьерная история: сначала был миддл, потом стал ведущим разработчиком на проекте, затем возглавил Android-отдел в Рамблере. Ну и наконец, перешел в Яндекс на позицию руководителя мобилки на проекте.
Тут история в трех актах. Хотелось бы рассказать вдохновляющую историю о том, как я что-то сложное запрограммировал в 10 лет, но нет. Началось все, когда мне было лет 6 – с компьютерных игр. Позднее иногда баловался с MS Paint, Powerpoint (почему-то мне это казалось интересным), Corel Draw. Но это случалось редко и бессистемно. Большую часть времени я играл. И все это время в голове сидело чувство, что это все, конечно, хорошо, но было бы круто научиться делать с помощью компьютера что-то полезное и «серьезное».
В 9 классе я увидел у старшего брата книгу по Turbo Pascal для студентов-первокурсников и неожиданно заинтересовался программированием. Я перешел из своей школы в лицей информационных технологий, а оттуда осознанно поступил в универ на специальность «Информационные системы и технологии». Я не до конца понимал, чем хочу заниматься, т.к. я очень плохо представлял продакшен-разработку. Но знал, что хочется работать в сфере, связанной с компьютерами.
Ну и последний, третий акт начался на втором курсе, когда я первый раз в жизни пошел по-настоящему работать. На втором курсе я подрабатывал эникейщиком в универе: научился настраивать, обслуживать и диагностировать компьютеры. На 4 курсе пошел работать на полставки в крупную госкомпанию в службу эксплуатации. Там еще удалось немного влезть в настройку сетей, сетевого оборудования и т.д.
К моменту выпуска из универа у меня был какой-то админский опыт с сетями и серверами, базовые знания программирования, но я не понимал до конца, чем хочу заниматься и не знал, как устроена разработка в «реальном» мире. Потом случайно узнал, что есть вакансия инженера-программиста в отделении РАН. Так я попал одновременно и в науку, и в какое-никакое программирование. Я писал на C# софтину для операторов крупного предприятия. Никакого rocket-science, но было интересно, хотя сейчас я понимаю, что наши поделки недалеко ушли от уровня универских лабораторных. К сожалению, не было рядом скиллового программиста, у которого можно было бы поучиться. Параллельно с основной работой я влез во фриланс-проект на PHP, где первый раз самостоятельно взаимодействовал с заказчиком.
— как получилось, что ты работал в Хабаровске бэкендером, а теперь хэд мобильной разработки в Яндексе?
Череда случайностей 🙂 Я работал java-бэкендером в Хабаровской компании, а в свободное время делал парочку фриланс-проектов под Android. Было интересно изучать что-то новое и обкатывать привычные подходы из бэкенда на андроиде. Потом в компании произошел ряд изменений, большинство стоящих сотрудников уволились. Я не стал исключением и начал собеседоваться везде, где только можно. В Хабаровске идти было некуда, поэтому я рассматривал релокацию в Москву или Питер. Изначально целился на бэкенд, но было интересно попробовать себя и в «серьезной» мобильной разработке. В итоге у меня было два оффера в Москву. Один на бэкенд в неизвестную мне на тот момент компанию, второй – на мобилку в Rambler. Рамблер был больше на слуху и условия предложили получше. Так я стал мобильным разработчиком. Ну а дальше типичная карьерная история: сначала был миддл, потом стал ведущим разработчиком на проекте, затем возглавил Android-отдел в Рамблере. Ну и наконец, перешел в Яндекс на позицию руководителя мобилки на проекте.
— как ты изучал андроид?
Когда я начал заниматься андроидом, у меня уже была база для понимания, что есть хороший код и хорошая архитектура, что – не очень. Помогли книги «Совершенный код» Макконелла и «Архитектура корпоративных программных приложений» Фаулера. А дальше – документация на developer.android.com как основной источник истины, статейки в интернете про отдельные тонкости и нюансы. Некоторые вещи было проще и интереснее изучать, глядя прямо в исходники.
И самое главное – практика. Например, узнав, что в андроиде образца 2015-2016 года для DI принято использовать Dagger, а в качестве архитектурного паттерна presentation layer’а – MVP, я сделал пару тестовых приложений, чтобы лучше разобраться, как правильно все это вместе готовить.
— с какими трудностями столкнулся, когда переходил на мобилку?
Хороший вопрос. Наверное, главная трудность – это Android SDK и его документация. В нем много нюансов (читай – «костылей»), которые постигаются только опытным путем. Первое время часто было так, что я делаю что-то по документации, а оно или совсем не работает, или работает не так. Потому что документация была печальная и на полноту претендовать не могла. Сейчас стало получше, но не идеально.
Ну и от фрагментации платформы никуда не денешься. Ужасно бесило тратить по 4-5 часов на баги, которые происходили только на конкретной модели телефона. Помню баг, что на одном самсунге цифра "7" отрисовывалась с противоестественным смещением по вертикали. В порядке бреда поменял файл шрифтов c otf на ttf. Всё починилось. Что? Как? Почему именно на этом телефоне? Ответа у меня до сих пор нет. Было трудно смириться с тем, что для Android это нормально 🙂
— это смешно. чем же мобайл круче бэка?
Несколькими аспектами.
Во-первых, результат труда среднестатистического мобильщика намного ближе к пользователю. Это та самая пресловутая история о том, что можно показать своей маме, что именно ты сделал в продукте. Несравнимо сложнее объяснить, что я написал сервисы бизнес-логики, а над ними сделал фасад, который вывел на контроллер API, откуда я отдаю клиентам json’ы.
Во-вторых, мобилка очень быстро развивается. В той же экосистеме java за последние пару лет поменялось меньше всего по сравнению с экосистемой android. Если хочется постоянно пробовать новые архитектурные паттерны, подходы и парадигмы – мобилка весьма подталкивает к этому.
В-третьих, мобилка сильно больше позволяет экспериментировать. Размер кодовой базы среднестатистического мобильного приложения не настолько огромен, чтобы не иметь возможности что-то радикально менять. Для многих приложений это нормальная часть жизненного цикла – раз в 2-3 года что-то кардинально переписывать или делать редизайн. Кто-то может себе позволить всё переписать с нуля, когда стало совсем сложно. Субъективно кажется, что в мобилках такое случается несколько чаще, чем в бэкенде.
Ну и наконец, и это сейчас 100% субъективный момент, мобильные коммьюнити в России сейчас одни из самых дружных и сплоченных.
Когда я начал заниматься андроидом, у меня уже была база для понимания, что есть хороший код и хорошая архитектура, что – не очень. Помогли книги «Совершенный код» Макконелла и «Архитектура корпоративных программных приложений» Фаулера. А дальше – документация на developer.android.com как основной источник истины, статейки в интернете про отдельные тонкости и нюансы. Некоторые вещи было проще и интереснее изучать, глядя прямо в исходники.
И самое главное – практика. Например, узнав, что в андроиде образца 2015-2016 года для DI принято использовать Dagger, а в качестве архитектурного паттерна presentation layer’а – MVP, я сделал пару тестовых приложений, чтобы лучше разобраться, как правильно все это вместе готовить.
— с какими трудностями столкнулся, когда переходил на мобилку?
Хороший вопрос. Наверное, главная трудность – это Android SDK и его документация. В нем много нюансов (читай – «костылей»), которые постигаются только опытным путем. Первое время часто было так, что я делаю что-то по документации, а оно или совсем не работает, или работает не так. Потому что документация была печальная и на полноту претендовать не могла. Сейчас стало получше, но не идеально.
Ну и от фрагментации платформы никуда не денешься. Ужасно бесило тратить по 4-5 часов на баги, которые происходили только на конкретной модели телефона. Помню баг, что на одном самсунге цифра "7" отрисовывалась с противоестественным смещением по вертикали. В порядке бреда поменял файл шрифтов c otf на ttf. Всё починилось. Что? Как? Почему именно на этом телефоне? Ответа у меня до сих пор нет. Было трудно смириться с тем, что для Android это нормально 🙂
— это смешно. чем же мобайл круче бэка?
Несколькими аспектами.
Во-первых, результат труда среднестатистического мобильщика намного ближе к пользователю. Это та самая пресловутая история о том, что можно показать своей маме, что именно ты сделал в продукте. Несравнимо сложнее объяснить, что я написал сервисы бизнес-логики, а над ними сделал фасад, который вывел на контроллер API, откуда я отдаю клиентам json’ы.
Во-вторых, мобилка очень быстро развивается. В той же экосистеме java за последние пару лет поменялось меньше всего по сравнению с экосистемой android. Если хочется постоянно пробовать новые архитектурные паттерны, подходы и парадигмы – мобилка весьма подталкивает к этому.
В-третьих, мобилка сильно больше позволяет экспериментировать. Размер кодовой базы среднестатистического мобильного приложения не настолько огромен, чтобы не иметь возможности что-то радикально менять. Для многих приложений это нормальная часть жизненного цикла – раз в 2-3 года что-то кардинально переписывать или делать редизайн. Кто-то может себе позволить всё переписать с нуля, когда стало совсем сложно. Субъективно кажется, что в мобилках такое случается несколько чаще, чем в бэкенде.
Ну и наконец, и это сейчас 100% субъективный момент, мобильные коммьюнити в России сейчас одни из самых дружных и сплоченных.
— а какие минусы у мобилки? или чем бэк круче?
У меня есть один спорный аргумент – в бэкенде я чаще сталкивался с объективно сложными задачами. Под словом «объективно» я подразумеваю какие-то не вендор-специфичные ограничения, которые обязан обходить. Здесь нужно продумать, как хранить данные денормализованно, чтобы искались быстрее. Сделать механизм транзакций, чтобы все не лочилось намертво. Решая такие задачи, ты понимаешь, откуда берутся ограничения, и они не вызывают у тебя баттхерта. В свою очередь в Android я слишком часто сталкивался с проблемами, которые вызваны только тем, что Android SDK неудобный и ни разу не developer-friendly. Бесчисленное количество раз приходилось сидеть и ловить себя на мысли, что уже в сотый раз пишешь костыли, чтобы просто отрисовать на экране список элементов, и он мог нормально, плавно скроллиться. Это не очень мотивирует.
Если обобщить, то в большинстве случаев мобилка – это тонкий клиент. Т.е. она получает данные с сервера и показывает их в своем интерфейсе. Пользователь жмет кнопку – данные пересылаются на сервер, сервер присылает ответ, клиент перерисовывает интерфейс. Всё. А вся «реальная» работа выполняется на сервере. Точно знаю, что для кого-то этот тезис валидный ответ на вопрос, чем бэк круче мобилки. После перехода из бэка в Android я первое время тоже так считал. Сейчас изменил свое мнение, т.к. все-таки одно без другого смысла не имеет, и просто некорректно сравнивать важность абсолютно разных задач.
В конечном итоге, я теперь понимаю, что никто не круче 🙂 Это просто разные инженерные задачи)
У меня есть один спорный аргумент – в бэкенде я чаще сталкивался с объективно сложными задачами. Под словом «объективно» я подразумеваю какие-то не вендор-специфичные ограничения, которые обязан обходить. Здесь нужно продумать, как хранить данные денормализованно, чтобы искались быстрее. Сделать механизм транзакций, чтобы все не лочилось намертво. Решая такие задачи, ты понимаешь, откуда берутся ограничения, и они не вызывают у тебя баттхерта. В свою очередь в Android я слишком часто сталкивался с проблемами, которые вызваны только тем, что Android SDK неудобный и ни разу не developer-friendly. Бесчисленное количество раз приходилось сидеть и ловить себя на мысли, что уже в сотый раз пишешь костыли, чтобы просто отрисовать на экране список элементов, и он мог нормально, плавно скроллиться. Это не очень мотивирует.
Если обобщить, то в большинстве случаев мобилка – это тонкий клиент. Т.е. она получает данные с сервера и показывает их в своем интерфейсе. Пользователь жмет кнопку – данные пересылаются на сервер, сервер присылает ответ, клиент перерисовывает интерфейс. Всё. А вся «реальная» работа выполняется на сервере. Точно знаю, что для кого-то этот тезис валидный ответ на вопрос, чем бэк круче мобилки. После перехода из бэка в Android я первое время тоже так считал. Сейчас изменил свое мнение, т.к. все-таки одно без другого смысла не имеет, и просто некорректно сравнивать важность абсолютно разных задач.
В конечном итоге, я теперь понимаю, что никто не круче 🙂 Это просто разные инженерные задачи)