Да ну, из 10 человек которые в зоне видимости, один ходил, и страдает на эту тему.
Остальным вся эта возня параллельно.
И что эта листовка делает здесь?
Каждый день, это обычная работа.
ЗП не меньше чем у программистов, по крайней мере в интернет компаниях.
Вообще малая зп у системных администраторов по такого рода исследованиям только из-за смешения теплого с мягким, усредняют зп админа администрирующего 100 — 200 рабочих станций + 2 — 3 сервера, и админа с тем же количеством серверов.
Я не только вовлечен в процесс выкатывания продукта, но и сам периодически являюсь инициатором изменений, т.к. вижу узкие места раньше программистов.
DevOps это фэйк.
Бред, DevOps это понты для поднятия зарплаты.
Занимаюсь администрированием более 10 лет, работал и на западные компании.
Роль в «программистских » проектах на уровне архитектуры системы, т.к. ограничения инфраструктуры лучше всего известна как раз администратору.
newtype — тип обертка, по всей видимости объявлен чтоб не писать длинную аннотацию и для объявления instance.
Внутри:
ReaderT XConf (StateT XState IO) a
Стэк монад, внутри есть read-only XConf, конфигурация.
+ XState — состояние, можно читать и писать.
Сразу по дефолту есть instance для следующих классов
(Functor, Monad, MonadIO, MonadState XState, MonadReader XConf, Typeable)
В коде это дает возможность применять следующие функции к объектам типа X
1. Functor
fmap :: (a -> b) -> f a -> f b
2. Monad
bind, return и тд
3. MonadState XState
get -> получить состояние
set -> изменить состояние на новое
+ еще некоторый набор связанных функций.
4. MonadIO
liftIO :: IO a -> m a
т.е. возможность выполнять IO в этой монаде.
5. MonadReader XConf
ask -> считать конфигурацию
+ связанные функции.
6. Typeable
typeOf :: a -> TypeRep
Для типа X имеем подпись типа.
Далее определенны еще несколько instance
7. Applicative
Набор функций рассмотрен в статье
8. (Monoid a) => Monoid (X a)
mempty -> нейтральный элемент
mappend -> комбинирование двух элементов одного типа, результат того же типа
для строки mappend «при» «вет» = «привет»
Все это понятно просто по аннотации типов.
Собственно весь код ниже.
-- | The X monad, 'ReaderT' and 'StateT' transformers over 'IO'
-- encapsulating the window manager configuration and state,
-- respectively.
--
-- Dynamic components may be retrieved with 'get', static components
-- with 'ask'. With newtype deriving we get readers and state monads
-- instantiated on 'XConf' and 'XState' automatically.
--
newtype X a = X (ReaderT XConf (StateT XState IO) a)
deriving (Functor, Monad, MonadIO, MonadState XState, MonadReader XConf, Typeable)
instance Applicative X where
pure = return
(<*>) = ap
instance (Monoid a) => Monoid (X a) where
mempty = return mempty
mappend = liftM2 mappend
Но я за долгое время так и не смог понять, чем хороши монады. Я понимаю, зачем они нужны в чистом функциональном языке, но я не понимаю, почему это это всё полезно и удобно при условии существования кучи других языков программирования. Я не понимаю, в чём «изящество» и мощь этих механизмов.
Ну если не понимаете, может это вам просто не нужно.
Я тоже много чего не понимаю, и меня это не сильно печалит.
И у меня есть стойкое ощущение, что единственное для чего они придуманы, это чтобы у адептов Haskell было постоянное развлечение в виде «напишу-ка я очередную статью о монадах, теперь с картинками!». Нет, ну реально. Ещё ни разу не видел статью о монадах вида «я придумал крутую монаду XYZ, теперь мой код стал понятнее на 50% и короче на 60». Зато, при этом есть куча статей с объяснениями того, что такое монада в Haskell. Разве это не является признаком того, что с практической точки зрения монада — это какой-то странноватый инструмент?
Ну не знаю, статей на тему монад не писал, да и желания не возникало.
Мониторю www.reddit.com/r/haskell/
Засилья статей на тему монад не замечаю, попадаются иногда, но не до фанатизма.
Да и нормальный это инструмент, если понимаешь что это и как его применять.
Как бы… Эмс… То, что существует множество разных языков программирования не наталкивает вас на мысль, что эти языки нужны для решения различных задач? IMHO, тотально глупо считать, что Haskell, Python, Bash и C позволяют одинаково хорошо решать разные задачи.
Языки это инструменты, если я знаю haskell, erlang и bash, то задачи я буду решать с их помощью.
Даже если я понимаю что в данном случае С подойдет лучше, я его не знаю, пытался, но «не шмогла я не шмогла».
Большинство из этих пакетов — реализации примитивных структур данных, которые почему-то в других сообществах являются самоочевидными. Ну никто в мире Си не гордится тем, что реализовал набор queue-like data structures, даже студенты, которые хотят на халяву зачёт по курсовой получить.
Ну тут и сказать мне не чего.
Про гордость вообще не понятно.
Покажите мне реальные приложения. Я вот когда-то смотрел на darcs и frag, первый меня убил обилием кода на Си, второй ужасными конструкциями с несколькими видами стрелок, за каждой из которых стояла какая-то перестановочная семантика, отслеживание которой по коду в течении сотни строчек надолго привило мне стойкое неприятие Haskell. На Си у Кармака то же самое написано в 10 раз понятнее и лаконичнее. Так зачем тогда городить этот огород со стрелками? Не понятно.
ок.
Использую xmonad в качестве оконного менеджера. Работает, нравится.
Есть свой реальный код в реальной работающей инфраструктуре, работает, всех устраивает.
Пользуюсь облаком selectel, у них тоже что то на haskell.
А насчет понятнее на С, ну ради бога, мне понятнее на haskell.
На тему что такое абстракция спорить не буду, сильно это все вилами на воде писано.
Лопатой можно копать землю, а абстракциями оперировать можно только в уме.
А у каждого он свой, и уникальный.
Действия не правильные.
1. Распаковать из архива с установочного диска calc.exe и посчитать md5 хэш
2. Посчитать md5 у calc.exe из карантина
3. Сравнить, если одинаковые заменить avast, если разные, лечить систему либо переставлять.
1 пункт делать на другом компьютере. md5 установочного диска должен совпадать с одним из вариантов microsoft
chef puppet это конечно хорошо, но нормальное пакетирование пакетов и настроек в перспективе лучше.
По сути все настройки и конфигурации сводятся к наборам зависимых пакетов. Для клонирования машинки достаточно подключить репозиторий и установить те же пакеты что и на исходной машинке.
В общем не стоит придумывать велосипеды для того что уже давно придуманно.
Если программист под *nix не может упаковать свою программу в пакет, он по всей видимости ошибся с выбором профессии.
И не надо говорить что для этого есть системные администраторы, это не их зона ответственности.
Никто лучше автора не знает в каком окружении должна работать программа.
Мой слог желает лучшего, да и желания особого нет, я сейчас в основном код пишу.
На счет лога изменений:
при пересборке пакета меняется версия и вносятся коментарии в changelog, + в пакете есть полный список зависимостей.
Чего в системе контроля за версиями в принципе нет, а для развертывания это ой как нужно. Также в этом варианте нет контроля с какими параметрами собран пакет (пакеты), в общем это увеличивает время развертывания сервиса на порядки, и каждый раз это будут новые танцы с бубном.
Если используется пакетирование, то все сводится к одной команде aptitude install пакет,
который подтягивает по зависимостям все что ему требуется, включая сам софт и настройки.
Если требуется полностью скопировать сервер, это также умещается в одну — две команды.
Ничего хорошего, будет больше сервисов, людей, система станет не управляемой.
Потом появится вики с документацией по настройкам, потом на нее все забьют. И будут несколько носителей истины, их нельзя будет уволить, сложно заменить, да и не помнит человек всего.
Так делать нельзя.
Если хотите масштабируемый, управляемый, документируемый сервис, пакуйте в пакеты.
И конфигурации тоже.
Это не сложно, это нужно и обязательно.
1 телефон — какой то самсунг за 900 р.
параметры выбора:
a) должен звонить
b) sms
c) заряда должно хватать на неделю
пока смартфоны не будут держать заряд, менять не вижу смысла.
2 планшет — ipad new
параметры выбора
a) экран
b) простота и удобство инерфейса
c) время работы
сколько попугаев и тд, по барабану
3 компьютер
старый — asus revo 3160
2 гига, atom
сценарий использования:
веб, ssh, просмотр фильмов
os linux
desktop manager — xmonad
машинки хватало за глаза, пока не начал программировать на компилируемых языках, сменил в этом году,
теперь она выполняет роль домашнего сервера и телевизора на кухне.
новый — imac 27
сценарий использования тотже + компиляция
параметры выбора:
a) cpu + память (компиляторы кушают)
b) моноблок (достали провода)
c) ips экран (комфортно)
с автором соглашусь,
взять win 95 на старом железе и 7 на новом
скорость работы одинаковая
комфортность тоже.
1989 — пк Север (zx-spectrum)
1993 — Электроника МС 0511
1998 — уже пеньтиум
1999 — первый выход в интернет, чат www.krovatka.ru
2000 — выделенка в 2 мегабита, видеоконференция Питер — Москва
Листовка — статья.
Остальным вся эта возня параллельно.
И что эта листовка делает здесь?
ЗП не меньше чем у программистов, по крайней мере в интернет компаниях.
Вообще малая зп у системных администраторов по такого рода исследованиям только из-за смешения теплого с мягким, усредняют зп админа администрирующего 100 — 200 рабочих станций + 2 — 3 сервера, и админа с тем же количеством серверов.
Я не только вовлечен в процесс выкатывания продукта, но и сам периодически являюсь инициатором изменений, т.к. вижу узкие места раньше программистов.
DevOps это фэйк.
Занимаюсь администрированием более 10 лет, работал и на западные компании.
Роль в «программистских » проектах на уровне архитектуры системы, т.к. ограничения инфраструктуры лучше всего известна как раз администратору.
Внутри:
ReaderT XConf (StateT XState IO) a
Стэк монад, внутри есть read-only XConf, конфигурация.
+ XState — состояние, можно читать и писать.
Сразу по дефолту есть instance для следующих классов
(Functor, Monad, MonadIO, MonadState XState, MonadReader XConf, Typeable)
В коде это дает возможность применять следующие функции к объектам типа X
1. Functor
fmap :: (a -> b) -> f a -> f b
2. Monad
bind, return и тд
3. MonadState XState
get -> получить состояние
set -> изменить состояние на новое
+ еще некоторый набор связанных функций.
4. MonadIO
liftIO :: IO a -> m a
т.е. возможность выполнять IO в этой монаде.
5. MonadReader XConf
ask -> считать конфигурацию
+ связанные функции.
6. Typeable
typeOf :: a -> TypeRep
Для типа X имеем подпись типа.
Далее определенны еще несколько instance
7. Applicative
Набор функций рассмотрен в статье
8. (Monoid a) => Monoid (X a)
mempty -> нейтральный элемент
mappend -> комбинирование двух элементов одного типа, результат того же типа
для строки mappend «при» «вет» = «привет»
Все это понятно просто по аннотации типов.
Собственно весь код ниже.
Легко ищутся по запросу типа
instance FromJSON
для примера
hackage.haskell.org/packages/archive/github/0.7.0/doc/html/src/Github-Data.html
io-streams
conduits
pipes
Выбрать что больше нравится.
Ну если не понимаете, может это вам просто не нужно.
Я тоже много чего не понимаю, и меня это не сильно печалит.
Ну не знаю, статей на тему монад не писал, да и желания не возникало.
Мониторю www.reddit.com/r/haskell/
Засилья статей на тему монад не замечаю, попадаются иногда, но не до фанатизма.
Да и нормальный это инструмент, если понимаешь что это и как его применять.
Языки это инструменты, если я знаю haskell, erlang и bash, то задачи я буду решать с их помощью.
Даже если я понимаю что в данном случае С подойдет лучше, я его не знаю, пытался, но «не шмогла я не шмогла».
Ну тут и сказать мне не чего.
Про гордость вообще не понятно.
ок.
Использую xmonad в качестве оконного менеджера. Работает, нравится.
Есть свой реальный код в реальной работающей инфраструктуре, работает, всех устраивает.
Пользуюсь облаком selectel, у них тоже что то на haskell.
А насчет понятнее на С, ну ради бога, мне понятнее на haskell.
На тему что такое абстракция спорить не буду, сильно это все вилами на воде писано.
Лопатой можно копать землю, а абстракциями оперировать можно только в уме.
А у каждого он свой, и уникальный.
Чтобы писать программы.
Затем же зачем нужны C, C++, Java, Python и остальные языки программирования.
Есть.
http://hackage.haskell.org/packages/archive/pkg-list.html
foreign — в книге всего одна глава из 28, и это далеко не все примеры.
небезопасные массивы тоже есть, но в очень малом количестве случаев.
Может вначале почитать книгу?
Любой оператор, любого языка программирования суть есть абстракция.
>>> :t getLine — смотрим тип для getLine
getLine :: IO String — (f a) Упакованная строка
>>> :t readFile — смотрим тип для readFile
readFile :: FilePath -> IO String — (a -> f b) Функция из строки возвращает упакованное значение
>>> :t (<*>) — смотрим тип для <*>
(<*>) :: Applicative f => f (a -> b) -> f a -> f b
а вот тут и нестыковка
f(a -> b) хотя у нас a -> f b
а вот >>= как раз подходит
>>> :t (>>=)
(>>=) :: Monad m => m a -> (a -> m b) -> m b
Вторую фразу не понял.
1. Распаковать из архива с установочного диска calc.exe и посчитать md5 хэш
2. Посчитать md5 у calc.exe из карантина
3. Сравнить, если одинаковые заменить avast, если разные, лечить систему либо переставлять.
1 пункт делать на другом компьютере. md5 установочного диска должен совпадать с одним из вариантов microsoft
По сути все настройки и конфигурации сводятся к наборам зависимых пакетов. Для клонирования машинки достаточно подключить репозиторий и установить те же пакеты что и на исходной машинке.
Если программист под *nix не может упаковать свою программу в пакет, он по всей видимости ошибся с выбором профессии.
И не надо говорить что для этого есть системные администраторы, это не их зона ответственности.
Никто лучше автора не знает в каком окружении должна работать программа.
На счет лога изменений:
при пересборке пакета меняется версия и вносятся коментарии в changelog, + в пакете есть полный список зависимостей.
Чего в системе контроля за версиями в принципе нет, а для развертывания это ой как нужно. Также в этом варианте нет контроля с какими параметрами собран пакет (пакеты), в общем это увеличивает время развертывания сервиса на порядки, и каждый раз это будут новые танцы с бубном.
Если используется пакетирование, то все сводится к одной команде aptitude install пакет,
который подтягивает по зависимостям все что ему требуется, включая сам софт и настройки.
Если требуется полностью скопировать сервер, это также умещается в одну — две команды.
Потом появится вики с документацией по настройкам, потом на нее все забьют. И будут несколько носителей истины, их нельзя будет уволить, сложно заменить, да и не помнит человек всего.
Так делать нельзя.
Если хотите масштабируемый, управляемый, документируемый сервис, пакуйте в пакеты.
И конфигурации тоже.
Это не сложно, это нужно и обязательно.
PS более 10 лет системного администрирования
просто, быстро, со вкусом )
параметры выбора:
a) должен звонить
b) sms
c) заряда должно хватать на неделю
пока смартфоны не будут держать заряд, менять не вижу смысла.
2 планшет — ipad new
параметры выбора
a) экран
b) простота и удобство инерфейса
c) время работы
сколько попугаев и тд, по барабану
3 компьютер
старый — asus revo 3160
2 гига, atom
сценарий использования:
веб, ssh, просмотр фильмов
os linux
desktop manager — xmonad
машинки хватало за глаза, пока не начал программировать на компилируемых языках, сменил в этом году,
теперь она выполняет роль домашнего сервера и телевизора на кухне.
новый — imac 27
сценарий использования тотже + компиляция
параметры выбора:
a) cpu + память (компиляторы кушают)
b) моноблок (достали провода)
c) ips экран (комфортно)
с автором соглашусь,
взять win 95 на старом железе и 7 на новом
скорость работы одинаковая
комфортность тоже.
1993 — Электроника МС 0511
1998 — уже пеньтиум
1999 — первый выход в интернет, чат www.krovatka.ru
2000 — выделенка в 2 мегабита, видеоконференция Питер — Москва
Каждый использует наиболее удобный для себя инструмент.
Кому то удобно плодить if else
кому то использовать Maybe.
Кто то не может осилить haskell, кто то java.
Дело не в инструменте, дело в головах и руках.