Русский
Русский
English
Статистика
Реклама

Блог компании ruvds.com

Перевод Как мы раскрыли 24-летний баг в ядре Linux

22.02.2021 12:20:43 | Автор: admin

Захватывающий детективный рассказ о поиске и исправлении трудноуловимого и при этом весьма странного бага, который неведомым образом ускользал от обнаружения на протяжении долгих лет взросления системы Linux. В начале описывается предыстория и технологическая база компании, в которой этот баг постигло разоблачение, после чего автор подробно демонстрирует все предпринятые для его раскрытия шаги.

Здесь в Skroutz в составе нашего стандартного набора инструментов мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных, которые он использует в разработке. Обновление при этом происходит ежедневно в виде конвейера, который включает формирование LVM-снимков данных производственной среды, анонимизацию этого датасета путем удаления всей личной информации и его последующую передачу через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют ZFS-снимок каждому разработчику вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.

Для предоставления данных MariaDB и MongoDB с общими размерами датасетов в 600ГБ и 200ГБ, соответственно, мы используем такой же конвейер, а для Elasticsearch несколько иной его вариант. Несмотря на то, что данные на дисках существенно изменяются для всех источников, rsync все равно экономит немало времени, каждую ночь передавая приблизительно 1/3 всего датасета.

Такая настройка работала отлично более пяти лет и при этом была масштабирована с 15 до 150 разработчиков. Тем не менее, как и большинство крупных систем, требовала она недюжинного обслуживания, в ходе которого возникали весьма интересные моменты.

К таким моментам можно отнести проблему, которая в итоге привела к раскрытию поистине старого бага ядра Linux, связанного, в частности, с реализацией TCP. Дело в том, что передача rsync от исходного сервера по неочевидным причинам начала постоянно зависать, хотя в остальном все работало в штатном режиме. Более того, как в итоге выяснилось, эту проблему невозможно было воссоздать намеренно, хотя некоторые действия (например, добавление ограничения скорости на уровне rsync) снижали частоту ее появления, диапазон которой составлял от 1-2 раз в неделю до 1 раза в три месяца.

По началу мы не придали этой проблеме должного внимания из-за наличия более актуальных и важных задач, пометив ее как состояние гонки в rsync, которым как-нибудь нужно заняться, и использовали уже описанный обходной путь с ограничением скорости передачи.

Но в итоге она начала возникать буквально ежедневно.

rsync как конвейер


Хоть это и не обязательно, но знание внутреннего принципа работы rsync поможет вам понять последующий анализ. На сайте приводится подробное описание внутренней архитектуры этой программы, так что я просто обобщу наиболее важные пункты:

  1. rsync запускается как один процесс на клиенте и один процесс на сервере, взаимодействующие через пару сокетов. При использовании же демона rsync, как в нашем случае, коммуникация выполняется через простое TCP-соединение.
  2. В зависимости от направления синхронизации после завершения начального рукопожатия каждая конечная точка получает роль отправителя либо получателя. В нашем случае клиент выступает как получатель, а сервер как отправитель.
  3. Получатель создает ветку дополнительного процесса, называемого генератор, который использует тот же сокет, что и процесс получателя. Генератор определяет, что ему нужно запросить у отправителя, после чего отправитель посылает эти данные получателю. В итоге после этого шага мы, по сути, получаем конвейер: генератор -> отправитель -> получатель, где стрелки отражают два направления одного TCP-соединения. Несмотря на то, что в процессе присутствует система уведомлений, конвейер оперирует с использованием блокировки и для контроля обратного потока опирается на буферы ОС и окна получения TCP.

Призрак в сети?


Когда мы только столкнулись с проблемой, то первым делом предположили наличие в сети ошибок, что было вполне логичным, так как незадолго до этого был произведен апгрейд серверов и свитчей. Исключив всех стандартных подозреваемых (баги прошивки NIC, связанные с разгрузкой TSO/GSO/GRO/VLAN, чрезмерным отбрасыванием пакетов или CRC-ошибками свитчей и т.д.), мы пришли к заключению, что здесь все в порядке, и проблема кроется в чем-то другом.

Присоединение зависших процессов при помощи strace и gdb оказалось не особо информативным: генератор подвисал на send(), а отправитель и получатель на recv(), но при этом никакие данные не перемещались. Тем не менее при рассмотрении ядра обоих систем мы обнаружили кое-что интересное. Клиентский сокет rsync, совместно используемый процессами генератора и получателя, находился в следующем состоянии:

$ ss -mito dst :873State      Recv-Q Send-Q                  Local Address:Port                                 Peer Address:PortESTAB      0      392827              2001:db8:2a::3:38022                             2001:db8:2a::18:rsync                 timer:(persist,1min56sec,0) skmem:(r0,rb4194304,t0,tb530944,f3733,w401771,o0,bl0,d757) ts sack cubic wscale:7,7 rto:204 backoff:15 rtt:2.06/0.541 ato:40 mss:1428 cwnd:10 ssthresh:46 bytes_acked:22924107 bytes_received:100439119971 segs_out:7191833 segs_in:70503044 data_segs_out:16161 data_segs_in:70502223 send 55.5Mbps lastsnd:16281856 lastrcv:14261988 lastack:3164 pacing_rate 133.1Mbps retrans:0/11 rcv_rtt:20 rcv_space:2107888 notsent:392827 minrtt:0.189

На сервере же состояние сокета было таким:

$ ss -mito src :873State      Recv-Q Send-Q                Local Address:Port                                 Peer Address:PortESTAB      0      0                   2001:db8:2a::18:rsync                              2001:db8:2a::3:38022                 timer:(keepalive,3min7sec,0)  skmem:(r0,rb3540548,t0,tb4194304,f0,w0,o0,bl0,d292) ts sack cubic wscale:7,7 rto:204 rtt:1.234/1.809 ato:40 mss:1428 cwnd:1453 ssthresh:1431 bytes_acked:100439119971 bytes_received:22924106 segs_out:70503089 segs_in:7191833 data_segs_out:70502269 data_segs_in:16161 send 13451.4Mbps lastsnd:14277708 lastrcv:16297572 lastack:7012576 pacing_rate 16140.1Mbps retrans:0/794 rcv_rtt:7.5 rcv_space:589824 minrtt:0.026

Интересно то, что на клиенте генератор запрашивает с сервера отправку 3.5Мб данных (1 в первой выводе). Однако в то время как Recv-Q сервера пуст, и он способен принимать данные, ничто не передается. Если бы Recv-Q во втором выводе не равнялся нулю, то мы бы наблюдали зависание rsync на сервере и его невозможность считывать из сети данные. Тем не менее здесь мы видим, что rsync получил все входящие данные, и его вины тут нет.

Так почему же данные на одном конце соединения выстраиваются в очередь, когда второй конец вполне может их принять? Ответ незатейливо кроется в полях timer обоих выводов ss, в частности в timer:(persist,1min56sec,0). Цитируем ss(8):

-o, --options              Show timer information. For TCP protocol, the output format is:              timer:(<timer_name>,<expire_time>,<retrans>)              <timer_name>                     the name of the timer, there are five kind of timer names:                     on : means one of these  timers:  TCP  retrans  timer,  TCP                     early retrans timer and tail loss probe timer                     keepalive: tcp keep alive timer                     timewait: timewait stage timer                     persist: zero window probe timer                     unknown: none of the above timers

persist означает, что соединение получило уведомление о нулевом окне и ожидает от пира уведомления о ненулевом.

Нулевые окна TCP и зонды нулевых окон


В TCP управление потоком реализуется путем ограничения передаваемых данных с помощью скользящего окна, называемого окном получения. Если коротко, то каждая сторона TCP-соединения объявляет, сколько данных она может буферизовать при передаче, то есть сколько данных другая сторона может отправить, прежде чем перейти к ожиданию подтверждения их получения.

Когда буфер получения (Recv-Q) одной стороны заполняется (в данном случае, потому что процесс rsync выполняет на диске операции ввода/вывода со скоростью меньшей, чем скорость сети), эта сторона отправляет сигнал нулевого окна, который приостанавливает передачу по данному направлению. Когда в конечном итоге буфер освобождается, ядро отправляет незапрашиваемое уведомление с ненулевым окном, и передача данных возобновляется. Для верности на случай потери этого уведомления встречная сторона регулярно опрашивает состояние соединения, используя так называемые зонды нулевого окна (Zero Window Probes), режим persist, который мы здесь и наблюдаем.

Окно заело в закрытом состоянии


Настало время копнуть поглубже и использовать tcpdump для оценки происходящего на уровне сети:

 []09:34:34.165148 0c:c4:7a:f9:68:e4 > 0c:c4:7a:f9:69:78, ethertype IPv6 (0x86dd), length 86: (flowlabel 0xcbf6f, hlim 64, next-header TCP (6) payload length: 32) 2001:db8:2a::3.38022 > 2001:db8:2a::18.873: Flags [.], cksum 0x711b (incorrect -> 0x4d39), seq 4212361595, ack 1253278418, win 16384, options [nop,nop,TS val 2864739840 ecr 2885730760], length 009:34:34.165354 0c:c4:7a:f9:69:78 > 0c:c4:7a:f9:68:e4, ethertype IPv6 (0x86dd), length 86: (flowlabel 0x25712, hlim 64, next-header TCP (6) payload length: 32) 2001:db8:2a::18.873 > 2001:db8:2a::3.38022: Flags [.], cksum 0x1914 (correct), seq 1253278418, ack 4212361596, win 13831, options [nop,nop,TS val 2885760967 ecr 2863021624], length 0[ repeats every 2 mins]

Первый пакет это клиентский зонд нулевого окна, второй пакет это ответ сервера. Удивительно, что сервер объявляет ненулевое окно с размером 13831 байт1, которое клиент, по всей видимости, игнорирует.

В действительности умноженное на 128, так как фактор масштабирования окна равен 7.

Мы, наконец, сдвинулись с мертвой точки, и теперь есть над чем работать. В какой-то момент клиент столкнулся с объявлением сервера о нулевом окне, как частью стандартного управления потоком TCP, но затем по непонятной причине окно не открылось повторно. Клиент по-прежнему игнорирует объявляемые сервером обновления окна, поэтому передача стоит.

Обработка TCP-ввода в Linux


На данный момент очевидно, что TCP-соединение находится в странном состоянии на клиенте rsync. Поскольку управление TCP-потоком происходит на уровне ядра, для обнаружения корня проблемы нужно посмотреть, как ядро обрабатывает входящие TCP-подтверждения и постараться выяснить, почему оно игнорирует входящие объявления о состоянии окна.

Обработка TCP-пакетов происходит в net/ipv4/tcp_input.c. Несмотря на то, что в пути прописан компонент ipv4, этот код по большей части общий для IPv4 и IPv6.

После некоторых поисков мы выяснили, что входящие обновления окна обрабатываются в tcp_ack_update_window, а фактическое обновление контролируется следующей функцией:

/* Проверка доступности обновления окна. * Функция предполагает, что snd_una<=ack<=snd_next. */static inline bool tcp_may_update_window(const struct tcp_sock *tp,const u32 ack, const u32 ack_seq,const u32 nwin){returnafter(ack, tp->snd_una) || after(ack_seq, tp->snd_wl1) || (ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd); }

Переменные ack, ack_seq, snd_wl1 и snd_una содержат порядковые номера TCP для отслеживания переданных данных. Эти номера являются 32-битными беззнаковыми целыми числами (u32) и увеличиваются на 1 при каждом переданном байте, начиная с произвольного стартового значения (начальный порядковый номер). Вот их сводка:

  • ack_seq номер входящего сегмента.
  • Ack номер подтверждения, содержащийся во входящем сегменте. Он подтверждает порядковый номер последнего сегмента, полученного от нас пиром.
  • snd_wl1 номер входящего сегмента, который последним обновил окно получения пира.
  • snd_una номер первого не подтвержденного сегмента, то есть отправленного, но еще не подтвержденного пиром.

Будучи целыми числами фиксированного размера, порядковые номера в конечном итоге будут циклически повторяться, поэтому в условиях такого повторения сравнение двух номеров поручается макросу after().

В качестве справки заметим, что имена snd_una и snd_wl1 взяты непосредственно из первой спецификации TCP в RFC 793(англ.) 1981 года!
Выражая довольно запутанную проверку простым языком, мы хотим получать обновление окна от пира, если он:

Подтверждает получение отправленных нами данных.

Отправляет новые данные после предыдущего обновления окна.

Не отправляет новые данные после обновления окна, но объявляет окно большего размера.

Обратите внимание, что сравнение ack_seq и snd_wl1 гарантирует, что окно не будет обновлено случайно (повторно передаваемым) сегментом, который уже был просмотрен.

В нашем случае окно должно повторно открываться по меньшей мере согласно условию , но этого не происходит. Для выяснения причины нам нужно обратиться к указанным переменным. К сожалению, они являются частью внутреннего состояния ядра и не раскрываются непосредственно в пространстве пользователя. Здесь потребуется смекалка.

Доступ к внутреннему состоянию ядра


Для получения доступа к состоянию ядра нужно каким-то образом выполнить внутри него код. Одним из способов было пропатчить ядро несколькими вызовами printk() в нужных местах, но это потребовало бы перезагрузки машины и ожидания очередного зависания rsync. Вместо этого мы решили пропатчить ядро в реальном времени при помощи systemtap(англ.), использовав следующий скрипт:

probe kernel.statement("tcp_ack@./net/ipv4/tcp_input.c:3751"){  if ($sk->sk_send_head != NULL) {  ack_seq = @cast(&$skb->cb[0], "tcp_skb_cb", "kernel<net/tcp.h>")->seq  printf("ack: %d, ack_seq: %d, prior_snd_una: %d\n", $ack, ack_seq, $prior_snd_una)  seq = @cast(&$sk->sk_send_head->cb[0], "tcp_skb_cb", "kernel<net/tcp.h>")->seq  end_seq = @cast(&$sk->sk_send_head->cb[0], "tcp_skb_cb", "kernel<net/tcp.h>")->end_seq  printf("sk_send_head seq:%d, end_seq: %d\n", seq, end_seq)  snd_wnd = @cast($sk, "tcp_sock", "kernel<linux/tcp.h>")->snd_wnd  snd_wl1 = @cast($sk, "tcp_sock", "kernel<linux/tcp.h>")->snd_wl1  ts_recent = @cast($sk, "tcp_sock", "kernel<linux/tcp.h>")->rx_opt->ts_recent  rcv_tsval = @cast($sk, "tcp_sock", "kernel<linux/tcp.h>")->rx_opt->rcv_tsval  printf("snd_wnd: %d, tcp_wnd_end: %d, snd_wl1: %d\n", snd_wnd, $prior_snd_una + snd_wnd, snd_wl1)  printf("flag: %x, may update window: %d\n", $flag, $flag & 0x02)  printf("rcv_tsval: %d, ts_recent: %d\n", rcv_tsval, ts_recent)  print("\n")     }}

Systemtap работает путем преобразования своих скриптов в Си и построения модуля ядра, который патчит его на горячую и переопределяет конкретные инструкции. Здесь мы переопределили системный вызов tcp_ack(), дописали свой код в его конец и сбросили внутреннее состояние TCP-соединения. Проверка $sk->sk_send_head != NULL предоставляет быстрый способ сопоставлять только соединения с ненулевым Send-Q.

Загрузка полученного модуля в ядро привела к следующему:

ack: 4212361596, ack_seq: 1253278418, prior_snd_una: 4212361596sk_send_head seq:4212361596, end_seq: 4212425472snd_wnd: 0, tcp_wnd_end: 4212361596, snd_wl1: 1708927328flag: 4100, may update window: 0rcv_tsval: 2950255047, ts_recent: 2950255047

Здесь нас интересует два момента: snd_wl1: 1708927328 и ack_seq: 1253278418. Дело не просто в том, что, как и ожидалось, они отличаются, а в том, что ack_seq меньше, чем snd_wl1, то есть отсчет значений ack_seq в определенный момент возобновился с начала, а значение snd_wl1 какое-то время не обновлялось. Воспользовавшись правилами арифметики последовательных чисел(англ.), можно выяснить, что эта конечная точка с момента последнего обновления snd_wl1 получила не менее 3.8ГБ.

Мы уже видели, что поле snd_wl1 содержит последний порядковый номер, использованный для обновления окна получения пира (а значит и нашего окна отправки) и в конечном итоге должно гарантировать защиту от обновления окон на основе старых сегментов. Все должно быть в порядке, если snd_wl1 какое-то время не обновится, но при этом отставание от ack_seq не должно становиться слишком большим, иначе возникает риск отклонения допустимых обновлений окна, как в нашем случае. Поэтому все выглядит так, будто ядро Linux по каким-то причинам не может обновить snd_wl1, что ведет к невозможности выхода из состояния нулевого окна.

После получения весомых доказательств неполадок в ядре пришло время сообщить об этом наверх.

Обращение в тех поддержку


Хорошенько переварив информацию, мы составили обращение к службе сетевого обслуживания Linux, в котором указали все, что удалось на тот момент выяснить, вместе со своими домыслами по этому поводу. Меньше, чем через два часа мы получили ответ вместе с патчем от Нила Кардуэлла.

Оказалось, что баг находился в быстром пути получателя объемных данных, то есть пути кода, который пропускает большую часть строгой дорогостоящей TCP-обработки с целью оптимизации производительности в типичных случаях получения большого объема данных. Это серьезная оптимизация, подчеркнутая еще 28 лет назад2 Ваном Якобсоном в его письме TCP receive in 30 instructions (TCP-приемник в 30 инструкциях кода). Очевидно, что реализация Linux, находясь в быстром пути получателя, не обновляла snd_wl1. Когда соединение использует быстрый путь слишком долго, snd_wl1 настолько отстает, что ack_seq опережает его на круг. Если же это происходит при нулевом окне получения, пропадает возможность повторного открытия этого окна, как и было показано выше. Более того, эта ошибка присутствовала в Linux, начиная с версии 2.1.8, которая датируется аж 1996 годом!

Данная оптимизация актуальна и по сей день: относительно недавняя попытка упростить код, удалив из него прогнозирование заголовков и связанные с ним пути файлов, потерпела неудачу по причине снижения производительности.

Получив патч, мы его сразу установили, затем пересобрали и развернули на подверженных проблеме машинах ядро, после чего стали ждать в надежде, что все пойдет как положено. Спустя пару дней, мы уже были уверены в корректности патча и отсутствии побочных эффектов.

После недолгого обсуждения итоговый коммит был размещен в linux-net, откуда перетек в основную линию Linux для 5.10-rc1. В конечном итоге он был внедрен в стабильные серии ядер 4.9 и 4.19, которые мы используем на наших системах Debian с версиями 4.9.241 и 4.19.153, соответственно.

Послесловие


Несмотря на то, что баг был исправлен, нас по-прежнему интересовала пара вопросов, а именно:

  1. Как возможно, что TCP-ошибка, которая ведет к зависанию соединений, оставалась незамеченной на протяжении 24 лет?
  2. Как получилось, что, работая с инфраструктурой из более 600 систем, выполняющих всевозможные виды ПО, мы заметили этот баг только при использовании rsync?

На эти вопросы сложно ответить определенно, но можно порассуждать:

  1. Эта ошибка не будет вызываться большинством протоколов L7. В синхронных протоколах запрос-ответ, например в HTTP, обычно каждая сторона будет потреблять все доступные данные перед отправкой. В таком случае, даже если snd_wl1 сделает круг, получатель объемных данных сохранит ненулевое окно и сможет отправить данные, в следствии чего очередное подтверждение обновит это окно и подстроит snd_wl1 через проверку в tcp_may_update_window. С другой стороны, rsync использует агрессивный конвейер, в котором сервер может отправлять многогигабайтные ответы, не получая в ходе этого процесса входящие данные. И даже использование rsync через SSH (достаточно распространенная комбинация), а не через простой TCP-транспорт, не выявляло эту неполадку, поскольку фрейминг/оповещение в SSH не позволял данным выстраиваться на сервере в очередь подобным образом.
  2. Независимо от протокола приложения, получатель должен сохранять нулевое окно в последнем пути достаточно долго (хотя бы на протяжении 2ГБ) для циклического обращения, но не настолько долго, чтобы ack_seq успел снова обогнать snd_wl1. Такой вариант возможен только если не будут утрачены пакеты, и не возникнут другие условия, способные вызвать сбой прогнозирования заголовка быстрого пути. На практике же такое очень маловероятно, поскольку TCP сам определяет пропускную способность сети, фактически вызывая утрату пакетов.
  3. Большинство приложений будут обрабатывать сетевые таймауты и либо давать сбой, либо переподключаться, что будет похоже на случайный глюк сети, не оставляющий следов для отладки.

Наконец, даже если ничто из вышеперечисленного не происходит, и ваше TCP-соединение регулярно зависает, потребуется немало усилий, чтобы добраться до корней проблемы в коде ядра. Однако этот непростой процесс вознаградит вас увлекательным приключением, в котором вы многое узнаете об истории интернет-протоколов, заглянете в священные недра ядра и пронаблюдаете, как происходит решение подобных проблем в открытых проектах.

Если эта тема вам интересна, и вы относитесь к любителям поохотиться на странные баги, а также поразбираться в коде ядра, напишите нам мы постоянно ищем талантливых SRE и DevOps-инженеров!

Подробнее..

Bedrock Linux лего-набор для создания идеального linux-дистрибутива

22.02.2021 16:14:10 | Автор: admin


С момента появления Linux достаточно скоро возникло множество дистрибутивов: Slack, RedHat, Debian, SUSE и т. д. Тогда же возникла и проблема выбора дистрибутива, ведь каждый из них имеет свои особенности и преимущества, которые делают его особенным. RedHat и Debian наиболее стабильные и консервативные из дистрибутивов, Ubuntu заточен на удобство и имеет прекрасный пользовательский интерфейс, Gentoo свобода выбора и гибкость.

У каждого пользователя Linux были моменты, когда ему не хватало некоторых функций, реализованных в других дистрибутивах. Многим в свое время не понравилось, что Debian перешел на systemd и они создали на его основе новый дистрибутив Devuan. Некоторые перешли на Gentoo, где пользователь может создать среду с двумя системами инициализации: как с openrc, так и с systemd.

В разных дистрибутивах этот вопрос решается по-разному. Установка пакета, который отсутствует в штатном репозитории, решается с помощью docker-контейнеров, или использованием систем самодостаточных пакетов snap и flatpak. Можно даже ставить RPM пакеты на системах с пакетным менеджером DEB. В Gentoo имеется поддержка RPM и DEB пакетов. Все это работает, однако плохо масштабируется и не очень стабильно.

Создатели Bedrock Linux пошли дальше и создали полноценный мета-дистрибутив. В нем возможно использование не только пакетов, но и компонент различных Linux дистрибутивов, как кубиков Лего. В одном окружении можно создать систему из нескольких Linux OS, например установку дополнительных пакетов Ubuntu поверх базовых компонент Debian и Arch. Установочный скрипт доступен для следующих платформ.

  • aarch64;
  • armv7hl;
  • armv7l;
  • mips64el;
  • mips64;
  • mips;
  • mipsel;
  • ppc64;
  • ppc64le;
  • ppc;
  • s390;
  • x86_64;
  • x86;

Кстати, а почему установочный скрипт, а не полноценный установочный диск, или образ? Причина в том, что Bedrock Linux не имеет своего канонического дистрибутива, вместо этого имеется набор рецептов по сборке операционной системы из некоего набора ингредиентов. В этом Bedrock Linux похож на другой мета-дистрибутив Gentoo, однако в попытке объять необъятное продвинулся к самым границам здравомыслия, а возможно и перешел их.

Установка Bedrock и базовые команды


Используя уже установленный традиционный дистрибутив Linux с помощью установочного скрипта Bedrock трансформирует его в гибридную систему. Например, у вас уже установлена ОС Debian, с помощью установочного скрипта, вы получаете совмещенную среду с Ubuntu. Для начала надо запустить из под пользователя root.

sh ./bedrock-linux-<release>-<arch>.sh --hijack

Скрипт выдаст предупреждение, что это не учения.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * **                                                               ** Continuing will:                                              ** - Move the existing install to a temporary location           ** - Install Bedrock Linux on the root of the filesystem         ** - Add the previous install as a new Bedrock Linux stratum     **                                                               ** YOU ARE ABOUT TO REPLACE YOUR EXISTING LINUX INSTALL WITH A   ** BEDROCK LINUX INSTALL! THIS IS NOT INTENDED TO BE REVERSIBLE! **                                                               ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *Please type "Not reversible!" without quotes at the prompt to continue:> Not reversible!__          __             __\ \_________\ \____________\ \___ \  _ \  _\ _  \  _\ __ \ __\   /  \___/\__/\__/ \_\ \___/\__/\_\_\          Bedrock Linux 0.7.19 Poki

Самое время ознакомиться с таблицей совместимости Linux дистрибутивов. Основные популярные дистрибутивы имеют хорошую степень поддержки, кроме возможно OpenSUSE. Для Linux Mint не поддерживается выгрузка и автоматическое установка. Не надо также забывать про таблицу совместимости компонент между собой. Бинарники, например, переносятся хорошо из одного дистрибутива в другой, а шрифты плохо.

Если все проверки прошли успешно, скрипт вносит необходимые изменения в ОС, после чего нужно перезагрузить компьютер, чтобы изменения вступили в силу. С этого момента пользователь находится в окружении Bedrock Linux. Теперь можно установить дополнительную ОС в контейнер, называемый stratum нечто наподобие chroot окружения, в котором проделаны специальные дыры для коммуникации с другими strata.
Однако прежде, чем начинать желательно ознакомиться с руководством по эксплуатации, вызвав brl tutorial basics. Простейшие команды Bedrock, назначение каждой очевидно.

# brl update# brl version# brl ctatus

Просмотр списка доступных дистрибутивов и установка.

# brl fetch --list# brl fetch alpine# brl fetch void


Как взаимодействуют дистрибутивы в составе Bedrock?


В определенных ситуациях можно выполнять команды из разных strata так, как будто они часть одной привычной Linux OS. Например команды из void и alpine можно использовать в одном конвейере. Первая команда устанавливает пакет jq на alpine, вторая jo на void. Конвейер читает из второй и передает на первую, все происходит прозрачно для пользователя.

$ sudo apk add jq$ sudo xbps-install -y jo$ jo "distro=bedrock" | jq ".distro"

Первоначальная ОС Debian Linux, над которой произвели действие --hijack теперь также является всего лишь stratum. О её существовании можно догадаться, выполнив некоторые из этих команд.

$ brl which lsdebian$ brl which /debian

Более определенно, вывод этих команд будет совпадать с содержимым файла /etc/os-release, который виден из текущего процесса shell. Это логично, так как каждый stratum видит лишь свой локальный файл, иначе параллельно установленные Debian и Ubuntu споткнулись бы о содержимое файла /etc/apt/sources.list.

Однако, если бы все файлы были локальными разные дистрибутивы не смогли бы общаться между собой. Для того, чтобы это стало возможно необходимы глобальные файлы. Такие файлы действительно существуют.

$ brl which /bedrock/etc/bedrock.confglobal$ brl which /runglobal$ brl which /tmpglobal

Для тех случаев, когда процессам одного дистрибутива необходимо достучаться до локальных файлов другого, реализованы cross пути. Например чтобы из одной strata прочитать файл os-release другой нужно обращаться к ресурсам файловой системы используя путь /bedrock/strata/. Сам stratum bedrock служит лишь для cross чтения и записи файлов. Внутри crossfs файловая система FUSE, в которой запрашиваемые файлы перезаписываются на лету для обеспечения совместимости между различными strata.

$ brl which /bedrock/strata/bedrock/etc/os-release bedrock$ cat /bedrock/strata/bedrock/etc/os-releaseNAME="Bedrock Linux"ID=bedrockID_LIKE=bedrocklinuxVERSION="0.7.19 (Poki)"VERSION_ID="0.7.19"PRETTY_NAME="Bedrock Linux 0.7.19 Poki"HOME_URL="http://personeltest.ru/aways/bedrocklinux.org"$ brl which /bedrock/strata/my-alpine/etc/os-release my-alpine

Если необходимо выполнить внутреннюю команду определенной strata, следует воспользоваться соответствующим префиксом.

$ strat void sh -c 'apk --help'

Обновление Bedrock


Bedrock обновляется незатейливо и просто Как и все дистрибутивы Linux, достаточно запустить brl update из под пользователя root. Это команда обновит лишь stratum Bedrock, остальные strata обновляются своими штатными средствами: например yum update, или dnf update для Redhat и CentOS.

Удаление strata


Тоже ничего сложного сначала дистрибутив выключается, затем следует удаление.

$ sudo brl disable alpine$ sudo brl remove alpine$ sudo remove -d void

Последняя команда совмещает, операции disable и remove.

Для чего действительно нужен Bedrock Linux?


В этот момент многие читатели скорее всего задаются вопросом: для чего нужно скрещивать ежа с ужом и создавать гибридные ОС, ведь не всегда рабочая станция Linux сама по себе бывает достаточно стабильной, особенно с закрытыми драйверами графической карты, или в сессии Wayland. Попробуем перечислить некоторые сценарии использования Bedrock Linux в практике.
  • Вы предпочитаете стабильные дистрибутивы Linux, такие как RedHat и Debian, однако вам также необходима поддержка нового железа: CPU, или недавно приобретенный принтер. Чтобы получить эту поддержку необходимо установить более свежую версия ядра и пакетов cups, hplips. Такая задача может быть решена единожды, но стабильная система с нестабильными пакетами уже не то,
  • Вам нравится дистрибутив, но не его система инициализации. Скажем, systemd вы предпочитаете openrc, или runit, однако хотели бы при этом использовать Ubuntu.
  • У вас есть задача вести разработку, или сопровождать программное обеспечение для Linux, однако ваш дистрибутив отличается от целевого. Например sh скрипты написанные для bash не будут корректно выполнены в Debian, так как в нем /bin/sh не является ссылкой на /bin/bash. Для таких сценариев в Bedrock Linux достаточно добавить stratum для Debian Linux.
  • Вы пытаетесь изменить ваши представления об использовании Linux OS. Впрочем это уже не имеет отношение к практике.


Подробнее..

Перевод Мир JavaScript в 2021 году

23.02.2021 12:21:01 | Автор: admin
Мир веб-разработки весьма изменчив. Изменения в нём происходят очень быстро. Что принесёт в него 2021 год? Здесь я хочу поделиться выводами о грядущих крупных JS-трендах, которые я сделал, проанализировав соответствующие исследования, проведённые в 2020 году.




Сначала пара слов о самих этих исследованиях. К сожалению, какое-то время нам придётся обходиться без свежих материалов отличного Front End Tooling Survey. Это усложняет поиск трендов. И хотя в этом году на одно хорошее исследование стало меньше, вместо него появилось одно новое The State of Front End. Но оно проводится первый год, поэтому в нашем распоряжении нет его данных за прошлые годы, что, опять же, не способствует облегчению задачи поиска трендов. Правда, в нём приняло участие внушительное количество разработчиков со всего мира (4500), что, определённо, делает его ценным источником информации.

Менеджеры пакетов


В прошлом году я предлагал понаблюдать за развитием PNPM. Этот менеджер рассчитан на недопущение конфликтов версий пакетов и хорошо показывает себя при работе с монорепозиториями. Существуют люди, которые очень им увлечены, в прошлом году его репозиторий набрал 9500 звёзд на GitHub. PNPM, совершенно очевидно, привлёк на свою сторону немало разработчиков. Но мне кажется, что в 2021 году он вряд ли сможет серьёзно конкурировать с другими менеджерами пакетов. Дело в том, что Yarn и NPM используются в огромном множестве реальных проектов, и в том, сколько энергии команды разработчиков обоих этих проектов тратят на их развитие, на оснащение их новыми возможностями. Появление некоторых из этих новшеств стало непосредственной реакцией на наличие аналогичных возможностей у PNPM. Например это Рабочие области (Workspaces) Yarn. Это показывает важность конкуренции в развитии опенсорса.

Тестирование


В 2019 году Cypress и Puppeteer стали заметными новыми инструментами. Их успех продолжился и в 2020. Но Microsoft выпустила новый инструмент для сквозного тестирования, Playwright. Такое ощущение, что он появился буквально ниоткуда, но в 2020 году он набрал почти 20 тысяч звёзд на GitHub. У Microsoft, у самой большой в мире компании, занимающейся разработкой ПО, есть возможности для широкого продвижения своих разработок. Но это лишь частично объясняет популярность Playwright. Главная причина его популярности богатый функционал и возможность лёгкого перехода на него с Puppeteer.


Playwright возглавляет список тестировочных фреймворков. И это несмотря на то, что в 2019 году о нём ещё никто не знал

С тех пор как Сатья Наделла стал CEO Microsoft, у компании появился обычай выпускать популярные и мощные опенсорсные инструменты. Например VS Code.

Разновидности JavaScript


В прошлом году я говорил о том, что TypeScript, медленно, но верно, захватывает JavaScript-мир. Этот тренд усилился. Создатели бесчисленного множества опенсорсных проектов спешат включить TypeScript в список поддерживаемых этими проектами возможностей. Например, Deno, проект, репозиторий которого на GitHub стал самым звёздным JS-проектом в 2020 году, имеет встроенный компилятор TypeScript.

В прошлом году я, учитывая всеобщий интерес к статической типизации и функциональному программированию, рекомендовал понаблюдать за PureScript, в котором всё это есть. Но в 2020 году этот проект, так сказать, не взлетел, на GitHub ему досталось всего 641 новая звезда, а интерес к нему упал на 3%. Если учесть огромный разрыв между TypeScript и его конкурентами, можно сказать, что война языков окончена, и что выиграла её разработка Microsoft. Любому новому проекту очень нелегко будет привлечь внимание сообщества после тех лет, которые оно провело в размышлениях и в атмосфере, перенасыщенной разновидностями JavaScript.

Это та сфера, в которой я с радостью могу наблюдать единодушие сообщества. Теперь мы можем перестать отвлекаться на изучение различных надмножеств JavaScript и больше внимания уделить самому языку.

Фронтенд-разработка


В 2019 году больше всего GitHub-звёзд досталось фреймворку Vue. В то время это стало для всех большой новостью, это чётко указывало на то, что разработчики любят Vue. В 2020 году история повторилась. Но при этом рыночная доля React, если взглянуть на сведения по загрузкам NPM-пакетов, всё ещё огромна.


Загрузки React в прошлом году

При оценке популярности UI-фреймворков применимы ещё два полезных показателя. Это теги в GitHub и вакансии. Сейчас на GitHub имеется более 80000 репозиториев с тегом React, а с тегом Vue 25000. Если же взглянуть на рынок труда, то окажется, что в прошлом мае ресурс Career Karma сообщал о том, что на Indeed.com имеется 10005 вакансий React-разработчиков в США и лишь 1025 вакансий для Vue-разработчиков. Библиотека React буквально вездесуща, она хорошо выдерживает натиск сильных конкурентов.

Я не могу завершить этот раздел, не упомянув о Svelte и Angular. Фреймворк Angular всё ещё весьма популярен в прошлом году он набрал 13,3 тысячи новых звёзд на GitHub, каждую неделю его загружали из NPM почти 2,5 миллиона раз. Для кого-то, учитывая популярность React, это может показаться неожиданным, но закрывать глаза на эти сведения нельзя. Если говорить о Svelte, то инструмент это, в сравнении с другими похожими, очень молод. Но он, в исследовании State of JS, занял первую строчку по показателю удовлетворённости разработчиков. Правда, я ожидаю, что в 2021 году его популярность будет расти умеренными темпами. Дело в том, что React- и Vue-разработчикам для перехода на Svelte приходится взбираться на довольно-таки крутую кривую обучения.

Бэкенд-разработка


Сфера разработки серверных частей веб-проектов сейчас устроена довольно сложно. Здесь фреймворки для генерирования статических сайтов соседствуют с проектами, рассчитанными на создание API. Если немного во всём этом разобраться и сосредоточиться лишь на фреймворках, рассчитанных исключительно на серверы, то окажется, что позиции Express с 51500 GitHub-звёзд всё ещё весьма крепки. Но в интересующую нас область стремительно ворвался фреймворк Nest, который, только за 2020 год набрал 10300 новых звёзд на GitHub. В результате общее количество звёзд этого фреймворка достигло 33,6 тысяч. Разработчики прибегают к этому фреймворку, привлечённые тем, что он выдвигает строгие требования к проектам, создаваемым на его основе. Это способно ускорить разработку и упростить обслуживание готовых проектов. И, кстати, Nest использует TypeScript.

Если принять во внимание процветание фуллстек-фреймворков, то окажется, что сейчас на наших глазах разворачивается очень важная битва за сердца и умы разработчиков. Дело в том, что такие фреймворки оказывают огромное влияние на архитектуру и производительность приложений, на то, как именно эти приложения работают. В настоящий момент два подобных фреймворка, основанных на React NextJS и Gatsby, значительно популярнее своих Vue-конкурентов, но это лишь подтверждает всё то, что нам известно об экосистеме инструментов для фронтенд-разработки. Внимания же заслуживает то, насколько упал рейтинг удовлетворённости разработчиков фреймворком Gatsby. Отдельные наблюдения указывают на то, что при работе с этим фреймворком программисты сталкиваются с неприятным опытом, хотя есть и сведения о том, что это не так. Учитывая то, что фреймворк NextJS разработан Vercel, и то, что его оснащают возможностями по генерированию статических сайтов, я могу говорить лишь о том, что в этом году его привлекательность будет расти.

Инструменты для сборки проектов


В сфере инструментов для сборки проектов прямо сейчас видна острая конкурентная борьба. Несмотря на то, что разработчики жалуются на DevX Webpack, этот сборщик проектов, долгое время удерживавший пальму первенства в своей сфере, всё ещё занимает первое место среди конкурентов по объёму использования. В прошлом году можно было видеть, как в сферу сборщиков проектов пришёл Rome, в этом году к верхним строчкам отчётов проекта Rising Stars будут стремиться esbuild, Snowpack и Vite. Цель esbuild проста: ускорение процесса сборки проектов. Это, очевидно, весьма ценно для множества программистских команд и объясняет рост популярности данного инструмента.


Сборщики esbuild и Snowpack попали в верхние строчки соответствующего раздела исследования State of JS 2020

Одна из метрик популярности проектов это количество GitHub-звёзд. Но есть и другие показатели. Например, Snowpack стал первым в отчёте по технологиям, которые интересны разработчикам, и, что даже важнее, оказался в верхней части отчёта об удовлетворённости технологиями. Популярность Snowpack и Vite это недвусмысленное послание, говорящее нам о том, что сообщество серьёзно относится к нативным ES-модулям. Это крайне важная тема, так как выбор инструмента оказывает влияние на процесс сборки проектов, на кеширование, на соотношение модулей, используемых в разработке и в продакшн-окружении.

Инструменты для управления состоянием приложений


Существует ли UI-фреймворк, который можно назвать полным решением для разработки интерфейсов, не подключив к нему соответствующую библиотеку для управления состоянием приложений? Если не принимать во внимание споры о сопоставлении сложности решений с выгодностью их применения в расчёте на будущее, оказывается, что сфера управления состоянием приложений весьма интересна. Дело в том, что Redux испытывает давление с двух сторон: со стороны самой библиотеки React, и со стороны новых независимых разработок.

Я по собственному опыту знаю о мощи хуков React и API Context, но и у них есть свои ограничения. В любом случае, они, определённо, пользуются среди React-разработчиков большой популярностью, так как почти половина участников исследования State of Front End сообщила о том, что пользуется ими.


Раздел исследования State of Front End 2020, посвящённый инструментам для управления состоянием приложений

Итоги


В прошлогодней статье я исследовал вопрос консолидации. Казалось, что после многих лет разброда в сфере фреймворков и библиотек, мы наконец приходим к чему-то стабильному, к устоявшимся паттернам и практикам. Хотя я и полагаю, что эта тенденция продолжалась в 2020 году, очевидно то, что популярность JavaScript привела к возникновению новых инструментов в тех сферах, которые раньше были заняты исключительно другими языками. Например, эту мысль подтверждает растущее число E2E-фреймворков и инструментов для машинного обучения, основанных на JS.

Из данных 2020 года можно сделать один важный вывод: облик мира JavaScript-инструментов формируют крупные разработчики ПО. Так, TypeScript, разработка Microsoft, становится индустриальным стандартом, а у проектов, в которых используется этот язык, больше шансов добиться успеха. Хорошие примеры этого тренда NestJS и NextJS (которые не стоит путать).

На мир JavaScript оказывает влияние и JAMStack-подход к разработке проектов, и потребность в их высокой производительности. При этом растёт значимость генераторов статических сайтов и инструментов наподобие esbuild.

Мир JavaScript-инструментов продолжает расширяться, подпитываемый стремительным развитием функционала этих инструментов, поддержкой новых возможностей браузерами и платформами, на которых может выполняться JavaScript-код, и всё более широким проникновением цифровых технологий в нашу жизнь.

Чего вы ждёте от JavaScript-инструментов в 2021 году?

Подробнее..

Как написать простого бота для ВК и Телеграм

23.02.2021 18:07:11 | Автор: admin


Мы уже упоминали, как мы предоставляем бесплатные для студентов, чтобы они учились программировать. Один из наших подопечных Павел сделал простеньких телеграм и ВК ботов для FAQ. Они очень просте, тем не менее, начинающему программисту не помешают комментарии опытных ребят поэтому публикуем его рассказ Павел будет рад, если в комментариях ему дадут советы.

Я студент Новосибирского Государственного Технического Университета, не так давно мы с парочкой моих друзей реализовали во всех возможных областях научной деятельности. Мы помогаем сводить заинтересованных преподавателей и студентов всех ВУЗов Сибири, чтобы проектная научная деятельность развивалась по территории Сибири и РФ.

Студенты и преподаватели часто обращались ко мне с вопросами и я решил автоматизировать этот процесс, написав ботов для ВК и Телеграм.

На вход они принимают сообщения, а на выходе выдают либо текстовый ответ, либо специальную структуру данных, замаскированное под сообщение: инлайновые или висячие клавиатуры.

Я использовать Python версии 3.6 просто потому, что он самый простой для меня. Кодил в PyCharm Community Edition. Весь код опубликован на. Удачи!

1. Предварительные приготовления для телеграм-бота


1.1 Получение токена от Bot Father в телеграмме


Первым делом, нам нужно зарегистрировать нашего бота в Telegram.

Для этого, в поисковике телеги ищем BotFather

далее, делаем всё также, как показано на скриншотах:



После нажимаем на команду /newbot или же прописываем вручную.



Надо придумать уникальное имя для бота, придумываем и получаем соответствующий токен.



1.2 Переходим в любой редактор кода и создаем файл


Перед созданием данного файла, нам нужно выбрать директорию, в котором будет реализован весь функционал бота. Если вы используете PyCharm Community/Professional Edition, то предлагаю просто создать новый проект, и писать там весь функционал бота.

Если Вы используете любой другой редактор, такой как Sublime Text 3, например, то Вам самостоятельно придётся создать директорию, создать виртуальное окружение, и работать из консоли со всеми предварительными тестами. Во избежание трудностей, предлагаю скачать продукт PyCharm Community Edition от компании JetBrains, с помощью данного продукта можно обойти действия, описанные в предыдущем абзаце, так как данный продукт сделает их самостоятельно, от Вас потребуется только указать путь до интерпритатора Python в конфигурациях PyCharm, с помощью которого и будет работать Ваш бот.

В данном файле () будет храниться только токен, который нам дал BotFather, поэтому пишем:

token = "Здесь хранится Ваш токен".

1.3 Cоздаём главный файл


Делаем cледующие импорты и для соответствующих библиотек, в консоли прописываем закоментированные строчки:

import configimport telebot # pip install telebotfrom telebot import types # pip install pyTelegramBotAPI

Далее, нам необходимо использовать наш токен:

bot = telebot.TeleBot(config.token)

Этим действиям мы устанавливаем то, что мы будем накручивать функционал именно для того бота, для которого нам и дал токен BotFather.

2. Разворачиваем функционал


Начнём с того, что для того, чтобы пользователю запустить бота, нам необходимо прописать команды для старта они могут быть разными, например, /start или /go и вообще любыми, какими Вы сочтёте нужными.

Для обработки команд нам потребуется message_handler, с помощью которого и будет реализован весь функционал обработки команд для старта и завершения, если Вы сочтёте нужным добавить завершение. Как только придёт команда /go или /start, message_handler с соответствующими командами сравнит, совпадают ли строки и если совпадают, то обработает соответствующей функцией.

Каждая функция, как и в примере сейчас, должна принимать один параметр сообщение от пользователя, которое будет обработано соответствующей функции в обёртке декоратора. А также, каждая функция (или связка функций) должна возвращать соответсвующее сообщение от бота.

Итак:

@bot.message_handler(commands=['go', 'start']) # Обработка команды для стартаdef welcome(message):sti = open(path+'stiker.tgs', 'rb')bot.send_sticker(message.chat.id, sti)markup = types.ReplyKeyboardMarkup(resize_keyboard=True)item3 = types.KeyboardButton("Приложения")item2 = types.KeyboardButton("Мероприятия")item1 = types.KeyboardButton('О нас')markup.add(item1, item2, item3)bot.send_message(message.chat.id,"Добро пожаловать, {0.first_name}!\\n\\nЯ - <b>{1.first_name}</b>, бот команды Projector в НГТУ, ""создан для того, ""чтобы помочь Вам влиться в нашу команду,""просто узнать что-то о нас или же просто пообщаться и весело провести время.\\n\\n""<i>Have a nice time</i>".format(message.from_user, bot.get_me()),parse_mode='html', reply_markup=markup)

В этой функции реализовано сразу два действия: отправка приветственного сообщения и создание встроенной клавиатуры ReplyKeyboardMarkup, которая будет открыта, пока мы не завершим выполнения бота соответсвующей командой. Об этом будет сказано ниже.

Итак, пройдёмся по строчкам:

В строках 20-21: открывается стикер по тому пути к директории, в которой я его сохранил, после чего отправляется.

Строки 22-28: создаем встроенную клавиатуру, добавляя туда три элемента.

Строки 30-37: описано создание и отправка приветственного сообщения

Как вы можете заметить, метод send_message в строке 30, позволяет использовать HTML, для форматирования текста.

Строками ниже, добавим запуск самого бота, который будет хоститься, пока не случится ошибка или же, пока мы Сами его не закроем.

# RUNif __name__ == "__main__":try:bot.polling(none_stop=True)except ConnectionError as e:print('Ошибка соединения: ', e)except Exception as r:print("Непридвиденная ошибка: ", r)finally:print("Здесь всё закончилось")

Сделаем первый запуск! Для этого, в PyCharm-е нажмём зеленую кнопку старт в правом верхнем углу или же, можно запустить из консоли командой: python



Результат первого запуска:



2.1 Обработка нажатия на кнопки и создание inline keyboard


Так любое сообщение это текст, то мы будем обрабатывать именно текстовые сообщения.

Сделаем следующее и аналогично разберём по строчкам:

@bot.message_handler(content_types=["text"])def go_send_messages(message):if message.chat.type == 'private':if message.text == 'Приложения':keyboard = types.InlineKeyboardMarkup(row_width=1)itemboo = types.InlineKeyboardButton(text="Тыщ на кнопку и ты уже в Google", url="<https://www.google.ru>")itemboo1 = types.InlineKeyboardButton('Рандомное число', callback_data='good2')itemboo2 = types.InlineKeyboardButton("Калькулятор", callback_data='bad2')itemboo3 = types.InlineKeyboardButton("Хочу узнать погоду в моем городе/стране", callback_data='good3')itemboo4 = types.InlineKeyboardButton("Как твои дела?", callback_data='bad4')keyboard.add(itemboo, itemboo1, itemboo2, itemboo3, itemboo4)bot.send_message(message.chat.id,"{0.first_name}, окей, смотри, что у нас есть тут:\\n".format(message.from_user),reply_markup=keyboard)elif message.text == "Мероприятия":one_markup = types.InlineKeyboardMarkup(row_width=1)ite1 = types.InlineKeyboardButton("Ближайшие мероприятия", callback_data="one")ite2 = types.InlineKeyboardButton("Проведенные мероприятия", callback_data="two")ite3 = types.InlineKeyboardButton("Волонтерство на мероприятие", callback_data="three")ite4 = types.InlineKeyboardButton("Действующие проекты в НГТУ", callback_data="fourth")ite5 = types.InlineKeyboardButton("Мероприятия Межвузовского центра", callback_data="five")one_markup.add(ite1, ite2, ite3, ite4, ite5)bot.send_message(message.chat.id, "{0.first_name}, у нас <u>ежемесячно</u> проводится множество ""мероприятий,\\nмы постарались разбить их на следующие составляющие:".format(message.from_user), parse_mode="html", reply_markup=one_markup)

Строка 339 обработчик любых текстовых сообщений

Строка 341 предназначена для того, чтобы сказать, что если данное сообщение предназначено боту, то сравни эту строку с теми, что здесь обрабатываются и отправь ответ.

Строки 344 351 создаём инлайновую клавиатуру InlineKeyboardMarkup и помещаем в эту клавиатуру 5 элементов, которые также можно будет обработать по установленной callback_data. Элементы данной клавиатуры будут расположены друг под другом, так как в строке 344, мы установили row_width = 1, что обозначает самую широкую грань одной кнопки, поэтому они и будут расположены друг под другом.

Строки 353-355 отправляют текст, вместе с нашей Inline Keyboard.

В условиях ниже представлены аналогичные представления обработки сообщений.

Итак, сделаем запуск:

2.2 Обработка InlineKeyboardButton


Как было сказано выше, каждый элемент InlineKeyboardButton имеет параметр callback_data, и именно по этим параметрам будет обрабатываться каждая кнопка. Для этого нам потребуется обработчик инлайновой клавиатуры callback_query_handler.

@bot.callback_query_handler(func=lambda call: call.data in ['one', 'two', 'three', 'fourth', 'five']) # Мероприятияdef callback_inline_one(call):try:if call.message:if call.data == 'one': # Ближайшие мероприятияbot.send_message(call.message.chat.id,"Итак,<b>ближайшие мероприятия</b>:\\n\\n" # Здесь будут ссылки ещё"Форум Байкал\\n""Конкурс Цифровой ветер\\n""PRONETI", parse_mode="html")elif call.data == 'two': # Проведённые мероприятияbot.send_message(call.message.chat.id, "Вот список <b>проведённых мероприятий</b>:\\n\\n""МНТК\\n""Семинары по проектной деятельности\\n""Встреча с представителями предприятий", parse_mode="html")elif call.data == 'three':

Итак, разберём по строчно:

Строка 269 объявляем обработчик, который будет обрабатывать каждую из нажатых кнопок с использованием лямбда-функции

Строки 273-278 В данном блоке if, мы просто обрабатываем сообщение и отправляем сообщение пользователю.

Строки 279-283 Делают аналогичное действие, что и в предыдущем условном блоке.

и т. д.

Также, в данных блоках можно определить аналогичную инлайновую клавиатуру, только тогда придётся создать ещё один обработчик callback_data, аналогичный обработчику callback_query_handler, показанный на скриншоте выше.

Результат:



Так просто и обрабатываются inline keyboards.

3. Завершаем работу бота


Данная функция будет аналогичной функции обработки команд для старта бота, поэтому Вы сможете легко понять её функционал:

@bot.message_handler(commands=['stop']) # Обработка команды для выходаdef bye(message):bye_Sti = open(path+'byeMorty.tgs', 'rb')hideBoard = types.ReplyKeyboardRemove()bot.send_message(message.chat.id,"Досвидания, {0.first_name}!\\nМы, команда <b>{1.first_name}</b>, надеемся, что ты хорошо провел(а) время \\n\\n""Присоединяйся к нашей команде в <a href='<https://vk.com/projector_neti>'>vk</a>\\n""Наш <a href='<https://instagram.com/projector_neti>'>inst</a>\\n\\n""Напиши Координатору проектов (<a href='<https://vk.com/nikyats>'>Никите Яцию</a>) и задай интересующие тебя вопросы по <i>проектной деятельности</i>\\n\\n""Надеемся, что тебе ответят очень скоро \\n\\n""<u>Don't be ill and have a nice day</u> \\n\\n\\n""P.S.: Если есть какие-то пожелания или вопросы по боту, то напиши <a href='<https://vk.com/setmyaddresspls>'>мне</a>".format(message.from_user, bot.get_me()), parse_mode='html', reply_markup=hideBoard)exit()

Здесь происходит следующее:

  1. Отправляется прощальный стикер.

  2. Закрывается встроенная клавиатура (строка 44).

  3. Отправляется прощальное сообщение.


Так как мы используем bot.polling, с параметром none_stop = True, то пользователь может снова вознообновить общение с ботом при помощи команды /start или /go, обработка которых показано в пункте выше.

Результат:



ВК БОТ

Перейдём к реализации бота Вконтакте, написанном на том же родном языке Python, его основное отличие от предыдущего в том, что он был написан с использованием ООП, а именно класса. Внешне, он выполняет ту же миссию. Сама библиотека для написания вк бота намного проще телеграмм бота, поэтому разобраться в ней самостоятельно не составит большого труда. Итак, начнём.

1. Предварительные подготавления


Установим следующие библиотеки по тем же технологиям:

import vk_api # pip install vk-apiimport json  # pip install jsonfrom vk_api.longpoll import VkLongPoll, VkEventType

1.1 Получение токена для сообщества Вконтакте.


  1. На главной странице сообщества найти раздел Управление
  2. Работа с API
  3. Создать ключ. Выбираете нужные для вас пункты, которые будут доступны боту.

В итоге должно получиться примерно следующее:

Берем ключ и переходим в среду разработки и делаем следующее:

vk = vk_api.VkApi(token="Ваш_токен")

Далее следующее:

longpoll = VkLongPoll(vk)

На этом, закончим подготавления.

2. Разворачиваем функционал


Первым делом создадим файл

Cоздадим прототип встроенной клавиатуры ( всё с помощью документации VkBotAPI ).

main_keyboard = {"one_time": False,"buttons": [[{"action": {"type": "text","payload": "{\\"button\\": \\"1\\"}","label": "О нас"},"color": "positive"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"2\\"}","label": "Мероприятия"},"color": "positive"},{"action": {"type": "text","payload": "{\\"button\\": \\"3\\"}","label": "Приложения"},"color": "positive"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"4\\"}","label": "Контакты"},"color": "primary"}]]}

Затем переводим её в формат json, как требуется в документации:

main_keyboard = json.dumps(main_keyboard, ensure_ascii=False).encode('utf-8')main_keyboard = str(main_keyboard.decode('utf-8'))

Пример инлайн клавиатуры:

about_us_keyboard = {"inline": True,"buttons": [[{"action": {"type": "text","payload": "{\\"button\\": \\"1\\"}","label": "Основная информация"},"color": "positive"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"2\\"}","label": "Чем мы занимаемся ?"},"color": "primary"},{"action": {"type": "text","payload": "{\\"button\\": \\"3\\"}","label": "Где мы находимся ?",},"color": "positive"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"4\\"}","label": "Как попасть в команду ?",},"color": "primary"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"5\\"}","label": "Контакты",},"color": "secondary"}],[{"action": {"type": "text","payload": "{\\"button\\": \\"6\\"}","label": "Задать вопрос руководителю проекта",},"color": "negative"}]],}

Не забываем все используемые клавиатуры переводить в формат json:

about_us_keyboard = json.dumps(about_us_keyboard, ensure_ascii=False).encode('utf-8')about_us_keyboard = str(about_us_keyboard.decode('utf-8'))

Создадим функцию write_msg, для того, чтобы не мучиться с постоянной отправкой сообщений от бота:

def write_msg(user_id, message, key):vk.method('messages.send',{'user_id': user_id,'message': message,'keyboard': key,'random_id': random.randint(0, 2048)})

После создания всех прототипов, мы можем перейти к следующему шагу. ( к этому файлу мы позже вернёмся и доработаем обработку общения пользователя и нашего vk-бота )

2.1 Основной функционал (создаем файл vk_bot.py)


Мы не будем разрабатывать методы, которые будут выполнять, например, функцию парсинга времени или погоды, назовем их второстепенными. Я покажу лишь основной метод, который будет обращаться к этим второстепенным методам, для обработки тех или иных сообщений от пользователя. В конце статьи я выложу ссылку на свой GitHub, где Вы сможете самостоятельно просмотреть интересующий Вас функционал любого из метода. Итак:

Конструктор класса:

class VkBot:def __init__(self, user_id):self.USER_ID = user_idself._USERNAME = self._get_user_name_from_vk_id(user_id)self.my_str = ""self._COMMANDS = ["привет", "погода", "время", "пока"]self._inputMes = {"основная информация": answers.about_us1,"чем мы занимаемся ?": answers.about_us2,"где мы находимся ?": answers.about_us3,"ближайшие мероприятия": answers.events1,"проведённые мероприятия": answers.events2,"волонтёрство на мероприятие": answers.events3,"действующие проекты в нгту": answers.events4,"мероприятия межвузовского центра": answers.events5}

Последнее свойство класса inputMes это особый словарь, у которого значения ключей это текст из файла, где я расположил текст в виде строк, поэтому, чтобы не загромождать код я и вынес основной текст в другой файл.

(Пример кода из файла)

events1 = "Итак,ближайшие мероприятия:\\n\\n" \\"Форум Байкал\\n"\\"Конкурс Цифровой ветер\\n"\\"PRONETI"events2 = "Вот список проведенных мероприятий:\\n"\\"МНТК\\n"\\"Семинары по проектной деятельности\\n"\\"Встреча с представителями предприятий\\n"\\events3 = "По поводу этого критерия напиши Илье (<https://vk.com/ki1337ki>)\\n"\\"А также, ты можешь заполнить анкету, благодаря которой,\\n"\\"с тобой лично свяжется один из руководителей направления\\n"\\"или координатор проекта (<https://vk.com/nikyats>)"

Итак, основной метод класса это new_message, который принимает один параметр message, который обрабатывается соответствующим условным блоком и возвращает какое -то значение обратно туда, откуда был вызван.

def _get_user_name_from_vk_id(self, user_id):request = requests.get("<https://vk.com/id>" + str(user_id))bs = bs4.BeautifulSoup(request.text, "html.parser")user_name = self._clean_all_tag_from_str(bs.findAll("title")[0])return user_name.split()[0]def new_message(self, message):# self.my_str = " ".join(re.findall('[0-9]{2}', message))if message.lower() == self._COMMANDS[0]:return f"Привет, {self._USERNAME}!"elif message.lower() == self._COMMANDS[1] or message.lower() == "узнать погоду ":return self._get_weather()elif message.lower() == self._COMMANDS[2] or message.lower() == "узнать точное время ":return self._get_time()elif message.lower() == self._COMMANDS[3]:return f"До скорой встречи, {self._USERNAME}!"else:for key, value in self._inputMes.items():if message.lower() == key:return valuereturn "Не понимаю тебя "

3. Возвращаемся в и дописываем функционал


Теперь в первых строках нам необходимо проимпортить файл vk_bot. А также нам потребуется библиотека random.

import random # pip install randomfrom vk_bot import VkBot

После того, как мы объявили longpoll, дописываем основной функционал.

longpoll = VkLongPoll(vk)try:for event in longpoll.listen():if event.type == VkEventType.MESSAGE_NEW:if event.to_me:bot = VkBot(event.user_id)if event.text.lower() == "о нас":write_msg(event.user_id, "Немного о нашем проекте", about_us_keyboard)elif event.text.lower() == "мероприятия":write_msg(event.user_id, "Что ты хочешь узнать?", events_keyboard)elif event.text.lower() == "приложения":write_msg(event.user_id, "Посмотри, что есть здесь!", app_keyboard)elif event.text.lower() == "контакты":write_msg(event.user_id, "По любым вопросам можешь обращаться к:", contacts_keyboard)elif event.text.lower() == "задать вопрос руководителю проекта":write_msg(event.user_id, "У тебя есть возможность написать сообщение нашему Руководителю проекта",go_answer)elif event.text.lower() == "калькулятор":write_msg(event.user_id, "В разработке...", calc_keyboard)# elif event.text == " ".join(re.findall('\\d{2}', event.text)):#   write_msg(event.user_id, "Отлично, мы здесь", calc_keyboard)elif event.text.lower() == "как попасть в команду ?":write_msg(event.user_id, "Напиши координатору проекта - Никите\\n""или перейди на сайт проектной деятельности,\\n""найди проект номер 612 и подай заявку", in_team)else:write_msg(event.user_id, bot.new_message(event.text), main_keyboard)except Exception as e:print(e)

Как можете заметить, в условных блоках if и elif присутствует обработка тех сообщений, которые подразумевают под собой вывод инлайн или встроенной клавиатуры (в данном примере выводятся только инлайн клавиатуры). Сюда также можно добавить более сложные обработки сообщений, после которых обработка будет метаться туда сюда по блокам if и elif. Таким образом бот будет работать, пока не упадёт с ошибкой.

Другое дело обстоит с блоком else, здесь мы обращаемся как раз ко классу нашего Бота, после чего он аналогичным способом находит обработку сообщения и выводит результат. Это можно назвать вложенной обработкой, а так как вложенностей лучше избегать, то лучше использовать тот метод программирования бота, который как раз-таки реализован в телеграмм боте.

Заключение


Надеюсь, что после прочтения данной статьи, Вы как минимум поняли основной принцип создания своего Telegram или Vk бота, а как максимум легко сможете написать своего бота.

Как вы можете видеть, создать его функционал очень просто, особенно, если вы знаете основы языка Python.

Весь код опубликован в моём профиле GitHub:


Подробнее..

Перевод Рецепт раствора для омеднения любых поверхностей

24.02.2021 12:05:30 | Автор: admin

В статье представлен вариант экономичного и простого решения по замешиванию собственного раствора для гальванизации различных поверхностей с возможностью дальнейшей пайки. Как обычно, автор приводит множество фотографий и сопуствтвующее описание, а в конце дает сам рецепт.

3D принтеры отлично подходят для изготовления всевозможных корпусов, но сам по себе пластик, являясь диэлектриком, не обеспечивает нужного экранирования.

Когда мне понадобился корпус для новых трубок зарядочувствительного усилителя (ЗЧУ) и He3, я спроектировал такой вариант:



Спустя 6 часов я уже держал его в руках:




Магический этап


Самая интересная часть заключалась в омеднении этого корпуса изнутри. В линейке Tifoo есть аэрозольная медная краска, на которую после высыхания можно наносить гальваническое покрытие. Требуется это только для гальванизации не проводящих ток деталей.



После предварительной грунтовки эта краска отлично держится на PLA-пластике, для чего вполне хватает двойного нанесения.


Сразу скажу, что это недешевый вариант покрытия, и tifoo просят еще 30 баксов за электролит. Я же подумал, что сложного тут ничего нет и решил изготовить его сам.

Результатом первой безуспешной попытки оказался просто сульфат меди. Со второго раза я получил сульфат меди и серную кислоту, что уже дало некоторые положительные результаты. По крайней мере теперь медь начала оседать. Однако кристаллы получались слишком большими и совершенно неоднородными. Из-за обширной площади покрытия они быстро окислялись и т.д.

Здесь и был задействован магический компонент сахарин (орто-сульфобензимид). С ним кристаллы получились уже более мелкие и однородные. Самое же главное, что теперь осадок не зависел от геометрии электрода.


Без сахарина

Без сахарина

С сахарином

Этот раствор хорош тем, что им можно гальванизировать практически все (кроме цинка, хрома, алюминия, титана, олова и железа). К тому же его можно паять!


Гальванизированная скандинавская золотая монета. Только посмотрите, насколько четкие детали!

Гальванизированный графит. Можно даже разглядеть следы машинной обработки!

Припайка к ПЛА. По размеру капли видно, какой нагрев он может выдержать

Припайка к графиту

А вот готовый корпус для моего ЗЧУ, покрытый электролитом:





Инструкции


А теперь самая долгожданная часть.

Использовать нужно только дистиллированную воду температурой 25C, так как раствор очень чувствителен к загрязнениям.

Внимание: изопропиловый спирт все портит. Даже минимального осадка на поверхности после чистки будет достаточно, чтобы загубить весь электролит.

  1. Сначала сделайте раствор 96%-ой серной кислоты и воды из расчета 30г на литр.
  2. В него добавьте сульфат меди (пентагидрат) по 300г на литр и дождитесь полного растворения.
  3. Добавьте сахарин в соотношении 1г на литр.

Вот и все!

Электрическая часть


Покрываемая деталь должна быть катодом, и вам понадобится (чистый!) медный анод, при этом плотность тока должна составлять 20-30 мА на см2. Убедитесь, что анод расположен близко к детали и имеет не менее половины площади поверхности омедняемой детали.

На покрытие уходит от 10 минут до 1.5 часов, в зависимости от требуемой толщины. Но после определенного момента ее наращивание останавливается. Не знаю почему, в химии я не силен.

Подробнее..

Мы сваляли дурака как и почему IBM потеряла рынок персональных компьютеров

24.02.2021 16:18:54 | Автор: admin
image

История поражений и провалов не менее интересна, чем история взлетов. Тем более, когда речь идет об IBM легендарном голубом гиганте, определявшем развитие информационных технологий на протяжении всего 20 века.

12 августа 1981 г. Дон Эстридж представил публике персональный компьютер IBM PC. Презентация не вызвала ажиотажа, но уже через несколько лет компьютерами от IBM пользовались миллионы людей. А еще спустя немного времени от лидерства практически ничего не осталось: масштабный рынок ПК был вчистую проигран конкурентам, и в 2005 г. остатки этого бизнеса были проданы китайской компании Lenovo.

В недавно вышедшей монографии IBM: Падение и возрождение великой компании Д. Кортада попытался ответить на вопросы, как и почему, имея колоссальные ресурсы и опыт, корпорация не смогла удержаться на рынке персональных компьютеров.

Мы выбрали из исследования главное.

Инструмент для новых времён


История настольных компьютеров началась не в IBM. Сначала был микропроцессор Intel 4004 (1969 1971 гг.), и процессор 8080 (1974), затем любительские сборки на его основе и 400-долларовый набор Altair 8800. В 1977 г. Стив Джобс представил Apple II, Commodore машину PET, а Tandy TRS-80. На тот момент это были скорее игрушки, бытовая техника для нердов, с простенькими видеоиграми и скромными инструментами программирования на борту. И с ценником на три порядка меньше, чем серьезные бизнес-ЭВМ от IBM (мэйнфреймы), стоившие от миллиона долларов.

image
Стив Джобс и Apple II

Ситуация начала меняться с появлением востребованного программного обеспечения: в 1979 г. вышла программа VisiCalc, в следующем году текстовый процессор Wordstar, проданные большими для того времени тиражами. Настольные компьютеры заинтересовали коммерческих пользователей, и IBM, которая к концу 70-ых была безоговорочным лидером на рынке обработки данных (в том числе за счет революционного S/360), не могла пройти мимо этого факта: даже далекому от потребительского рынка руководству стало ясно, что на происходящее нужно было как-то реагировать.

И голубой гигант отреагировал. Причем совершенно экстраординарным для компании образом. План, который инженер Билл Лоу подготовил для Фрэнка Кэри (на то время главы корпорации), предполагал выделение под проект создания мини-компьютера отдельной, изолированной от других производственной площадки в Бока-Ратон. Это позволяло не только избежать принятых в IBM сложных порядков согласования проектов, но и держать происходящее в секрете от конкурентов (да и от собственных продавцов, с их скептическим отношением ко всему новому). А что еще интереснее, вместо нормальных для IBM 4-5-летних сроков, Лоу планировал реализовать проект всего за один год, в том числе за счет приобретения и использования готовых компонентов и стороннего программного обеспечения. Чипы покупали у Intel, табличные процессоры у Lotus, а поставщиком операционной системы стал молодой IT-предприниматель Билл Гейтс. Чтобы, в случае провала, шишки не летели в сторону корпорации, было принято решение оставить права на QDOS у Microsoft. Тогда это казалось умным и дальновидным решением

image
Рекламная кампания IBM PC.

Топ-менеджмент IBM отнесся к проекту с опаской, но добро было получено. Всего лишь за год команда Лоу (которого потом сменил Дон Эстрейдж) смогла совершить организационно-технологический прорыв и выпустить первый IBM PC. Сочетание удачной рекламной кампании (лицом системы сделали маленького бродягу Чаплина), грамотной системы дистрибуции и розничных продаж позволили уже в первый год отгрузить 200 000 штук и получить 1 миллиард долларов выручки. Такого триумфального результата не ожидал никто: предполагалось, что направление ПК будет небольшим побочным бизнесом, а главным так и останутся мэйнфреймы.

Воодушевленные успехом, инженеры из Бока-Ратона продолжали развивать направление: в 1983 г. вышла модель IBM XT, а на следующий год IBM AT. Доля IBM на рынке персональных компьютеров достигла 75%! Вместе с IBM развивалась вся индустрия, появлялись тысячи программ, предназначенных для ПК. Решающим фактором успеха автор книги считает необычную для корпорации модель вне-бюрократического выпуска продуктов. Пока команда Лоу-Эстрейджа работала как отдельная фирма внутри фирмы и жила по своим законам, ориентируясь на методы и подходы Гейтса и Джобса, а не на базовые принципы и традиционную корпоративную культуру IBM, всё шло именно так, как нужно.

В погоне за рынком


Но не тут-то было. В 1980 г. СEO компании стал Джон Опель, управленец, решивший оптимизировать деятельность всех направлений и крайне далекий от темы персональных компьютеров. Кстати, в то время многие менеджеры в IBM даже не пользовались электронной почтой, потому что это входило в обязанности их секретарей и ассистентов. Бизнес шёл хорошо: в 1981 г. доход IBM достиг $29 млрд, а в 1984 вырос до $46 млрд., акции подскочили в два раза. На повестке дня не погоня за инновациями и прорывы, а планомерное освоение рынка за счет наращивания производственных ресурсов. Как результат, команда Эстрейджа перестала быть независимой, потеряла связь с потребителями и увязла в бюрократической сети, от которой ее когда-то уберёг Кэри.

image
IBM PC Jr неудачный эксперимент и начало конца.

Выход в марте 1984 г. модели PC Jr. стал прологом к будущей катастрофе. У компьютера была неудобная крошечная клавиатура, а большая часть ПО была несовместима с другими персональными компьютерами IBM. То же касалось и периферии.

Казалось, машина стала всеобщим посмешищем. Продавцы компании ее игнорировали, не желая давать негодные или безответственные рекомендации клиентам. Они считали, что на кону стоял их личный кредит доверия ситуация, с которой ранее им нечасто приходилось сталкиваться. IBM понизила цену, добавила функции и убеждала дилеров продвигать машину, но безрезультатно. Эстридж взял вину на себя. Внутри IBM ходили слухи, будто компания потратила на разработку этой машины 250 миллионов долларов! Подразделение ESD попыталось продать остатки сотрудникам за несколько сотен долларов в качестве потенциальных рождественских подарков. Эта затея провалилась В тот день IBM потеряла все свое очарование в сфере ПК и уже никогда не сумела его вернуть.

Почему же так произошло? Причин было несколько. Первая ударившая по разработке бюрократия. В отличие от первых моделей, теперь проектирование проходило через весь многоступенчатый процесс согласований и утверждений, который принят в IBM чуть ли не с 1920-ых гг. Так что теперь конечный продукт отвечал внутренним требованиям компании, но был далек от потребителей. Второй фактор недооценка рынка ПК, темпов и направления роста и его особенностей со стороны руководства корпорации. В то время как все конкуренты удешевляли и быстро адаптировали производство к меняющимся реалиям на рынке комплектующих, IBM шла по пути фиксированных долгосрочных смет и проектов. Наконец, большой штат и корпоративный аппарат, требующий затрат на своё содержание, дополнительно раздувал себестоимость ПК, делая продукцию IBM неконкурентной ещё и в ценовом отношении.
Конкуренты поняли, что IBM де-факто задала технические стандарты для персональных компьютеров, поэтому разработали совместимые версии и стали выводить их на рынок быстрее, а продавать дешевле. Клиенты увидели, что клоны ничуть не хуже продуктов IBM и что у них имеется множество программных и сетевых инструментов.

Своеобразным символом завершения технологического лидерства IBM стала авиакатастрофа 2 августа 1985 г., в которой погиб Дон Эстридж, незадолго до этого из-за конфликта ушедший с поста главы отдела персональных компьютеров.

Колосс на глиняных ногах


Во второй половине восьмидесятых IBM продолжала продавать миллионы компьютеров, но прибыль на единицу продукции становилась всё меньше и меньше. Как и доля рынка. Увы, компания оказалась неспособна эффективно реагировать на изменения в использовании персональных компьютеров, это касалось, в числе прочего, и перехода к сетевым технологиям, и распространения пользовательских интерфейсов. Билл Лоу, занявший место Эстриджа, придерживался традиционного подхода к разработке: он был убежден, что персональные компьютеры и их программное обеспечение должны проходить такое же тщательное тестирование, как и остальные продукты компании.

Это означало, что никакое программное обеспечение нельзя выпускать на рынок до тех пор, пока ошибки (баги) не будут вычищены в максимально возможной степени. Все остальные разработчики программного обеспечения ценили скорость вывода продукта на рынок выше, чем качество. Они полагали, что лучше побыстрее выпустить продукт, который неплохо работает, дать пользователям возможность выявить проблемы, а затем оперативно их решить. Как оказалось, клиенты и разработчики были готовы мириться с риском того, что в программах могут оставаться баги.

С неповоротливостью столкнулась и система сбыта. Утверждение всех продаж и скидок проходило очень долго и через множество инстанций. Так, чтобы согласовать сделку на 6000 машин с American Standard, понадобился целый год и десятки совещаний!

Кроме того, Лоу допустил ряд серьезных стратегических ошибок. Например, отказался от сделки с Биллом Гейтсом, который в 1986 г. предлагал ему купить часть Microsoft (говорят, что из-за боязни антимонопольных претензий). Или сделал ставку на разработку OS/2: более 1000 программистов, бюджет $125 млн в год, и фактически провал после релиза. Или не торопился осваивать новые, более быстродействующие 386-ые чипы от Intel, которые взяли на вооружение конкуренты.
В IBM никак не могли смириться с закатом эпохи мэйнфреймов, хотя прибыль от них заметно снижалась. Многие клиенты заменяли большие ЭВМ на ПК из-за значительно меньшей стоимости вычислений, и, к несчастью для IBM, чаще всего это была продукция таких конкурентов, как Compaq и Sun. Компьютеры IBM плохо продавались и приносили мало прибыли из-за высокой себестоимости. В результате в 1986 г. прибыль сократилась на 27%, а выручка выросла всего на 3%.

На фоне низких финансовых показателей менеджмент решил провести сокращение и ротацию персонала, и, по мнению автора книги, это только ухудшило ситуацию: из-за непродуманной системы ротации из компании ушло огромное количество талантливых сотрудников. Жертвой ситуации стал и сам Лоу: в конце 1988 г. его сменил Джим Каннавино, одним из немногих достижений IBM при котором стал выход рабочей станции RS/6000. Воплотившая инновационную RISC-архитектуру, RS/6000 принесла свыше $4 млрд выручки за 1990 1992 гг. и стала символом того, насколько тяжело стали IBM даваться инновационные решения: если бы не бюрократия и внутрикорпоративные разногласия, продукт мог бы выйти на несколько лет раньше и спасти бизнес ПК и мэйнфреймов.

Отдельного места в этой истории заслужила операционная система OS/2. IBM и Microsoft работали над ней совместно, но чем дальше, тем меньше доверия и общего языка находили компаньоны, так что в итоге IBM продолжила развивать OS/2 самостоятельно. Тысячи разработчиков системы верили, что она станет новой эрой успеха IBM. Однако, несмотря на все усилия и гигантские затраты на производство, OS/2 не смогла завоевать быстро растущий рынок. В 1992 г. фиаско было уже очевидно: 15 миллионов копий DOS и 10 миллионов Windows, и всего лишь 2 миллиона копий OS/2, многие из которых поставлялись бесплатно. Окончательно надежды рухнули в октябре 1995 года, когда от использования OS/2 отказался ряд корпоративных клиентов, включая State Farm Insurance, Caterpillar и UPS. Как писал потом Лу Герстнер, по-видимому, мои коллеги не желали или не могли признать, что война закончена и они потерпели сокрушительное поражение: доля рынка Windows составила 90 процентов против 5 или 6 процентов OS/2.

Продано!


image
Офис компании Lenovo.

IBM не сдавалась и тянула бизнес персональных компьютеров вплоть до начала 2000-ых, когда главой компании стал Сэм Палмизано, признавший: Мы сваляли дурака. Мы не воспринимали ПК как платформу. В 2005 году он заключил сделку по продаже этого бизнеса китайской компании Lenovo. Автор исследования уверен, что этот шаг был умным, действительно креативным решением затянувшейся проблемы персональных компьютеров в IBM. На тот момент корпорация была третьим по величине производителем персональных компьютеров в мире, но испытывала гигантские проблемы с рентабельностью потребительского направления. С другой стороны, IBM продолжала наращивать присутствие на международном рынке IT-услуг, и Китай был приоритетным регионом. И в этом контексте сделка с Lenovo смогла убить двух зайцев наконец-то избавила корпорацию от низкодоходного бизнеса и дала доступ к крупнейшей растущей экономике Азии.

Эта сделка была одной из наиболее виртуозных за всю историю IBM, но для многих айбиэмовцев она тем не менее оставалась печальным финалом четвертьвековой главы в жизни компании.

Почему IBM провалило направление ПК?


Очевидно, что причиной кризиса были стратегические просчеты высшего руководства корпорации. Из-за неправильно расставленных приоритетов, неумения адаптироваться к рынку разработки ПО, приверженности олдскульным корпоративным ценностям, менеджмент IBM упустил возможности, которые были у него в руках, а Apple, Intel и Microsoft успешно воспользовались ее ошибками. Как отметили одни исследователи, если бы руководители IBM активно поддерживали персональный компьютер, если бы они позиционировали на рынке айбиэмовскую версию процессора и если бы они быстро вытеснили операционную систему Microsoft для персональных компьютеров, цена акций IBM никогда не рухнула бы так, как это произошло. И культура компании, с ее упором на гарантию занятости, осталась бы в целости и сохранности, вызывая восхищение у всего делового мира.

Другая причина это высокие операционные расходы, вызванные, с одной стороны, гигантским штатом корпорации (только над программным обеспечением работало на порядок больше сотрудников, чем в Microsoft), а с другой архаичной схемой распределения затрат, которая не учитывала реального экономической ситуации в подразделениях. В результате IBM получила неподъемную для потребительского рынка себестоимость продукции, из-за которой ее или просто не покупали, или покупали с дисконтом. Да, это было не столь важно на ранних этапах, но в решающих сражениях за долю рынка оказалось ключевой проблемой.

Наконец, еще один фактор, приведший к краху направления, это корпоративная культура IBM и мировоззрение, сложившееся в ходе ведения бизнеса в сфере мэйнфреймов. Традиции требовали создания стопроцентно айбиэмовской системы как способа оставаться доминирующей компанией, куда клиенты обращались бы за компьютерами в первую очередь, и в результате компания выбрасывала миллиарды на разработку собственных продуктов, вместо того чтобы эффективно использовать сторонние технологии. В то время как бизнес ПК быстро и отзывчиво эволюционировал в сторону гибких, ориентированных на рынок сетевых моделей поведения, IBM изо всех сил цеплялась за модель управления, пришедшую из старых добрых 1950-ых. Даже легендарная система сбыта IBM, с ее глубочайшим вниманием к потребностям покупателей, и та не смогла адаптироваться к новым реалиям: как и большинство клиентов, менеджеры не понимали, в чем смысл перехода на ПК, и продолжали продавать быстро устаревающие мэйнфреймы.

Вместо заключения


В 1980-е завершился триумфальный марш IBM, начатый еще в начале века. Успехи IBM в области мейнфреймов не сумели предотвратить упадка в большей части направлений ее бизнеса История IBM PC это история корпорации, которая сделалась слишком большой, слишком бюрократической и слишком обособленной.

Подробнее..

Беспроводная мини погодная станция с e-paper экраном на батарейках

25.02.2021 12:15:55 | Автор: admin
Приветствую всех читателей Habr! В своей сегодняшней статье хочу поделиться с вами своим новым устройством датчиком температуры, влажности и давления с функцией предсказания погоды. Датчик работает на микроконтроллерах nRF52. Данный проект это логическое продолжение этого проекта. В новом датчике используется дисплей на электронных чернилах размером 2.9 дюймов. В датчике установлен сенсор BME280, так же есть место под установку датчиков SI7021, HTU21D. Работает от батареек CR2450. Может передавать данные в системы Умного Дома, так же может работать в режиме без сети.




Для этого проекта был выбрана модель дисплея на электронных чернилах GDEH029A1 размером экрана 2.9 дюймов. Примерно через 3 месяца тестирования на смену этому дисплею производители выпустили на рынок новую модель GDEM029T94(V2 по версии Waveshare).
Старую модель стало трудно купить, поэтому пришлось добавлять поддержку нового дисплея в проект.



Характеристики дисплеев:
Разрешение: 296х128
Диапазон рабочих температур: 0 50 C
Потребление в рабочем режиме: 3мА
Потребление в режиме глубокого сна: 1мкА
Минимальное время обновления экрана: 0.3 сек.

Разрабатывал сразу несколько вариантов плат под несколько вариантов радио модулей nRF52 от разных производителей. Остановился на модулях MINEW MS50SFA2 (nRF52832) и EBYTE E73 2G4M08S1C (nRF52840), E73 2G4M08S1E (nRF52833).



Модуль MINEW MS50SFA2 имеет небольшие размеры, но не очень большое количество выведенных ножек. В моем проекте были задействованы все доступные ножки MS50SFA2. У модулей E73 ножек на много больше, поэтому впоследствии была разработана расширенная версия датчика. В раcширеной версии добавлен активный биззер, датчик освещенности MAX44009, заменены батарейки с CR2450 на ААА.

Схема датчика



Корпус датчика печатается на FDM 3D принтере, что бы добиться более или менее приличного вида, корпус после печати необходимо отшлифовать наждачной бумагой и отполировать. Так как у датчика есть светодиод, а в расширенной версии датчик освещенности, то в корпусе необходимо было сделать два сквозных отверстия, после сверления отверстий, они были залиты полимерной смолой для SLA 3D принтера и засвечены УФ лампой, после этого отполированы.





ПО датчика было сделано для работы в сети MySENSORS, это открытый проект домашней автоматизации. К слову, датчик будет нормально работать и без сети. На данный момент в проекте поддерживается работа с двумя моделями дисплеев GDEH029A1, GDEM029T94. Возможно позднее будет добавлена поддержка трехцветных дисплеев.

Опишу немного функционал устройства. Устройство при подаче питания осуществляет попытку поиска сети, если сеть не найдена, то устройство переходит в основной режим работы без работы в сети (не шлет данные), но периодически делает короткие запросы на поиск сети(~раз в час). Интервал опроса сенсора один раз в минуту, обновление экрана и отправка данных(если сеть доступна) происходит при изменении данных температуры на 0.5C, влажности на 1%, давления на 1 единицу, уровня освещенности на 1 люкс, изменения прогноза по погоде. Интервал опроса батарейки задается пользователем в интервале от 1 часа до 24 часов, по умолчанию опрос один раз в 6 часов.

Датчик может настраиваться внешними командами из интерфейса УД. Для этого необходимо активировать нужный пункт меню конфигурация датчика нажатием кнопки меню. После активации режима конфигурации датчик перейдет в режим прослушивания на 20 секунд. В этот интервал необходимо отправить команду. Внешними командами можно настроить интервал проверки батарейки, изменить вывод информации на экран в инверсии, отключить индикацию светодиода, отключить звуковой сигнал.

Описание алгоритма расчета прогноза погоды (NXP Application Note 3914 | John B. Young)

При работе в радиосети датчик передает данные:
  • Температура,
  • Влажность,
  • Атмосферное давление,
  • Уровень освещенности,
  • Прогноз погоды,
  • Уровень сигнала,
  • Уровень заряда батарейки,
  • Причина перезагрузки






Для компиляции нужной версии ПО необходимо сконфигурировать файл MyConfig.h.
В файле задаются:
  • Язык вывода информации (RU,ENG)
  • Режим оптимизации питания при передаче данных
  • Подключение датчика освещенности
  • Подключение активного биззера
  • Скорость передачи данных
  • Версия подключенного дисплея


//#define EINK_V1#define DCPOWER#define LIGHTSENS#define BIZZER#define LANG_EN//#define MY_DEBUG//#define MY_PASSIVE_NODE//#define MY_NODE_ID 101#define MY_RADIO_NRF5_ESB#define MY_NRF5_ESB_MODE (NRF5_1MBPS)//#define MY_NRF5_ESB_MODE (NRF5_250KBPS)#define MY_RESET_REASON_TEXT#define SN "EFEKTA WeatherStation 290"#define SV "0.45"


Потребление датчика в режиме сна составляет в среднем 3мкА (на nRF52840 больше), в режиме считывания сенсора и обновления экрана 5мА(среднее), в режиме передачи данных 8мА(среднее), время передачи одного сообщения 10мc (идеальные условия).

Проект датчика в варианте с модулем MINEW MS50SFA2 может быть легко повторен. Из сложных моментов можно выделить пайку разъема под шлейф экрана. Как это сделать проще рекомендую посмотреть мое короткое видео по пайке разъема. Так же датчик можно приобрести готовым, тем самым поддержав мои открытые разработки.

Видео пайки разъема



Фото датчика

















Видео с демонстрацией работы датчика



GitHub проекта github.com/smartboxchannel/

В файле readme находится инструкция по установке и настройке среды для редактирования и компиляции ПО для датчика.

В завершении сделаю небольшой фото анонс проектов с которыми в скором времени поделюсь и о которых раскажу.

Новые проекты на стадии тестирования
Датчик качества воздуха на батарейках с e-paper экраном(аналогов не нашел)









Мини датчик влажности почвы с e-paper дисплеем(аналогов не нашел)










Если вам интересно все что связано с DIY, вы являетесть DIY разработчиком или хотите только начать, вам интересно использование DIY девайсов, а так же хотите узнавать первыми о моих проектах, то приглашаю всех заинтересованных в телеграм чат DIYDEV.

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors телеграм-чат MySensors

А тем кто ищет достаточно взрослые решения для домашней автоматизации приглашаю в телеграм-чат Open Thread. (что такое Thread?)

Спасибо за внимание, всем добра!

Подробнее..

Перевод BASIC. Кроссплатформенное ПО тогда и сейчас

25.02.2021 16:13:17 | Автор: admin


Удивит ли вас, если я скажу, что BASIC все еще не утратил свою актуальность? Помимо того, что этот язык явился прародителем современных домашних вычислительных систем, он все еще остается жизнеспособным даже вне кругов ретро-энтузиастов. Предлагаем окунуться в краткий обзор истории его становления, начиная с азов и заканчивая современными реализациями.

Истоки языка


Еще не так давно BASIC был общепринятым языком домашних компьютерных систем. Причем это не всегда был один и тот же BASIC. Его команды и синтаксис отличались в зависимости от модели ПК, которой он оснащался, будь то Commodore, Atari, Texas Instruments, Sinclair или другие. К счастью, большая часть диалектов проистекала из наиболее популярной реализации, а именно Microsoft BASIC.

Корнями BASIC уходит в академическую сферу, где он изначально создавался как язык, который был бы удобен как для профильных студентов, так и для тех, кто обучался вне традиционных областей STEM (Науки, Технологии, Инженерии и Математики). Унаследовав ряд свойств от популярных языков 60-х годов, таких как FORTRAN и ALGOL, он получил широкое распространение в школьных системах разделения времени. Даже IBM приняли участие в его развитии, выпустив в 1973 году более совершенную версию VS-BASIC. Когда в 70-х годах начали появляться микрокомпьютеры, которые были невелики и одновременно доступны по цене, то вполне естественным для них стало использование именно BASIC.

Преимущество интеграции этого языка в подобные системы было очевидным и заключалось не только в том, что он уже был знаком многим потенциальным покупателям компьютеров, но также и в его возможности выполнять программы без предварительной компиляции. Это было большим плюсом, потому что компиляция требует приличного объема ОЗУ и хранилища, а этими характеристиками микрокомпьютеры тех лет похвастаться явно не могли. Вместо компилирования исходного кода интерпретаторы BASIC преобразовывали и выполняли код построчно, теряя таким образом скорость в угоду гибкости и пониженному потреблению ресурсов.

При включении микрокомпьютера, как правило, прямо из встроенного ПЗУ загружался именно интерпретатор, а не полноценная операционная система. Из его оболочки можно было использовать аппаратное обеспечение, писать и загружать программы BASIC, а также записывать их на пленку или диск. Помимо этого, пользователь мог выполнять как имеющийся код, так и скомпилированные программы и даже вводить их прямо из листингов, которые печатались в журналах. При этом относительная согласованность между реализациями BASIC для разных домашних ПК обеспечивала отличную портативность.

Но это было тогда, а что сейчас? Используют ли этот язык сегодня?

BASIC + джойстик = веселуха


Для начала предлагаю получше рассмотреть принцип действия этого языка. В качестве очень простого, но в то же время забавного, примера его использования мы разберем приложение для Commodore 64, которое перемещает по экрану стрелку, выводя при этом на дисплей ее координаты. В качестве устройства ввода используется джойстик, подключенный ко второму порту. В качестве ПО выступает Commodore BASIC 2.0, являющийся диалектом Microsoft BASIC.

10 S=2: X=150: Y=150: V=53248: GOTO 100 15 J=PEEK(56320): IF J=127 THEN 15 20 IF J=111 THEN POKE 56322,255:END 25 IF J=123 THEN X=X-S 30 IF J=119 THEN X=X+S 35 IF J=125 THEN Y=Y+S 40 IF J=126 THEN Y=Y-S 45 IF J=122 THEN Y=Y-S 50 IF J=118 THEN Y=Y-S 55 IF J=117 THEN Y=Y-S 60 IF J=121 THEN Y=Y-S 65 IF X=>252 THEN X=10 70 IF X=<10 THEN X=252 75 IF Y>254 THEN Y=44 80 IF Y<44 THEN Y=254 85 PRINT CHR$(147);CHR$(158);CHR$(17);"X-POS:";X;" Y-POS";Y 90 POKE V,X:POKE V+1,Y: GOTO 15100 FOR Z=832 TO 853 : POKE Z,0: NEXT Z105 FOR Z=832 TO 853 STEP 3: READ J: POKE Z,J: NEXT Z110 POKE V+21,1: POKE  V+39,7: POKE V+33,0: POKE V+29,1115 POKE 56322,224: POKE 2040,13: GOTO 85120 DATA 240, 224, 224, 144, 8, 4, 2, 1

Каждая строка вводится как есть, включая ее номер. Завершив написание кода, переходим на следующую строку, вводим RUN и жмем Return (или Enter, зависит от клавиатуры). При условии, что все было введено верно, код будет выполнен, и на экране мы увидим:


В этой потрясной игре мы перемещаем стрелку по экрану с помощью джойстика

Так что же в реальности делает код? Как и в любой программе BASIC, он начинает выполнение с первой строки, в данном случае 10. Здесь определяется несколько переменных, после чего с помощью команды GOTO происходит переход к строке 100. В цикле FOR мы выполняем POKE (то есть производим запись в аппаратный регистр) и повторяем это еще в нескольких адресах, обновляя тем самым дисплей на его изначальную конфигурацию. Здесь команда READ используется для считывания констант, определяемых DATA.

Многие из этих адресов памяти напрямую обращаются к видео адаптеру (в C64 это VIC-II). Когда мы используем PEEK на строке 15, происходит считывание содержимого адреса памяти 56322, который соответствует текущим входным значениям на втором порту джойстика. После этого мы проверяем состояние каждого входа с помощью этих значений битов и нужным образом подстраиваем стрелку (строка 90) вместе с ее координатами (строка 85).

Посвященная этой программе страница C64 Wiki включает побитовую версию сравнения. Она должна выполняться чуть быстрее ввиду меньшего количества строк кода. Однако по перемещению стрелки на экране заметить это будет сложно.

Здесь важно подчеркнуть, что реализации BASIC на различных микрокомпьютерах подразумевали бы выполнение POKE и PEEK для разных адресов памяти, в связи с отличиями в конфигурации системы каждого компьютера. Некоторые реализации также предоставляли команды, привязанные к конкретной системе ПК, что стало более актуальным по мере роста их графических и аудио возможностей.

Интерпретация против компиляции



Знакомая многим картинка: QuickBasic IDE
Интерпретируемая природа BASIC на большинстве компьютеров была как преимуществом, так и недостатком одновременно. С одной стороны, он был очень гибок и позволял просто запускать программы, а также быстро их изменять, не требуя длительных циклов компиляции (как минимум на процессоре Z80 или 6502 с частотой < 10МГц). С другой стороны, ошибки в коде оставались незамеченными вплоть до момента выполнения программы интерпретатором. А это вело к такому же веселью при разработке, что и современные скрипты JS и Python, где код будет отлично выполняться, пока интерпретатор внезапно не выдаст сообщение об ошибке (это если повезет).

В случае BASIC данный казус обычно проявлялся в виде Syntax error on line <....>. При этом прогон того же кода через компилятор все эти ошибки бы выявил. Такая особенность интерпретируемых программ означала, что эффективность легкого распространения кода в виде листингов в компьютерных журналах и справочных руководствах определялась качеством печати и навыками самого вводящего этот код программиста. К счастью, на C64 и аналогичных системах исправление ошибочно введенных строк реализовывалось очень легко. Достаточно было ввести ее повторно, нажать Return, и интерпретатор производил обновление.

BASIC сегодня


Хотелось бы сказать, что все отлично, но сегодня уже никто не достает из кладовых тот старый C64, чтобы на досуге написать программу BASIC. За исключением, конечно, увлеченных любителей винтажных систем. И все же стоит заметить, что жизнь BASIC не закончилась с эпохой Commodore и Atari, и позже в Microsoft были разработаны его обновленные версии Visual Basic, Visual Basic for Applications (VBA) и VB.NET. На последнем можно писать VB-код для среды выполнения .NET.


PureBasic Visual Designer

Помимо этого, в 2008 году Microsoft выпустили Small Basic, нацеленный на начинающих программистов, например студентов, ранее использовавших визуальный язык программирования вроде Scratch. Причем его не стоит путать со SmallBasic, являющимся открытым (под стандартной общественной лицензией) диалектом BASIC с сопутствующими интерпретаторами для современных платформ.

Диалекты BASIC также можно встретить во многих графических и программируемых калькуляторах от Yi, HP, Casio и других производителей, хотя многие из этих диалектов не совместимы напрямую с изначальным стандартом BASIC (ISO/IEC 10279:1991). В процессе своего развития этот язык перешел от обязательной нумерации строк к перемещению по коду с помощью меток, а также обрел новые техники программирования. Эти изменения были введены в его обновленную версию QuickBasic в 1985 году и остаются актуальными по сей день.

Среди других реализаций можно выделить коммерческий PureBasic от Fantaisie Software, который предоставляет IDE и компилятор для ряда целевых платформ. TrueBasic, в свою очередь, является современным пакетом инструментов, включающим IDE, чей синтаксис больше приближен к FORTRAN. Разработан же он был самими создателями оригинального языка Darthmouth BASIC.

Что касается современных открытых интерпретаторов и компиляторов BASIC, то к ним относится Chipmunk Basic, восходящий еще ко времени Apple Macintosh, а также GW-BASIC от Microsoft, чей код был раскрыт не так давно. Кроме того, вокруг этого языка сформирована здоровая OSS-экосистема. Если же ничто из этого вас не тронет, то еще есть Tiny BASIC, использующий синтаксис в форме Бэкуса-Наура, как описано в первом выпуске Dr. Dobbs journal 1976 года. Несколько лет назад один из авторов Hackaday, Том Нарди, описал свой опыт переноса своего старого QuickBasic-проекта 90-х годов в современный формат с помощью QB64.

Подходящее применение


Становится очевидным, что BASIC не просто жив, но еще и повседневно используется в коммерческих формах, бесчисленных открытых проектах и деятельном сообществе увлекающихся ретро-компьютерами людей. Это конечно спорное заявление, но он по-прежнему годится в качестве языка для освоения программирования. Кроме того, благодаря более низким системным требованиям BASIC отлично подходит для создания встраиваемых приложений, что обычно делается на MicroPython и подобных языках. К примеру, несколько лет назад мы писали о микроконтроллере ARM, который поставлялся с интерпретатором BASIC на борту.

На GitHub также можно найти проекты, подобные UBASIC PLUS, который предназначен для STM32F0 и требует всего 8Кб ОЗУ и 64Кб флэш-памяти. Еще один проект для ARM и PIC32 (а также для DOS и Windows) это MMBasic, требующий 94Кб флэш и минимум 16Кб ОЗУ.

BASIC развивался в эпоху, когда у домашних ПК было меньше памяти и хранилища, чем у сегодняшних микроконтроллеров за $5. В связи с этим он оказывается прекрасным нетребовательным к ресурсам языком для случаев, когда нужно использовать интерпретируемые скрипты, а не скомпилированные двоичные файлы, и избавляет от необходимости приобретать микроконтроллер с большим объемом ОЗУ и флэш-памяти.

А пользуетесь ли вы, дорогой читатель, какой-либо формой BASIC сегодня?

Если да, поделитесь в комментариях своим опытом и советами для тех, кто может заинтересоваться этим языком, будь то на настольном ПК, винтажных-системах или встроенных.

Подробнее..

Перевод 5 причин, по которым я люблю программировать в Linux

26.02.2021 12:14:08 | Автор: admin
Linux это отличная платформа для занятий программированием. На нашей стороне логичность, высокая эффективность, лёгкость работы с исходным кодом.

В 2021 году Linux выглядит как никогда привлекательно. Я собираюсь написать материалы, в которых расскажу о 21 способе использования Linux. А в этой статье я хочу поговорить о том, почему так много программистов выбирают Linux.

Когда я начал пользоваться Linux, я работал в сфере кинопроизводства. Я выбрал Linux из-за того, что эта ОС замечательно поддерживала работу с мультимедийными данными. Мы выяснили, что обычные коммерческие приложения для редактирования видео не способны обрабатывать большинство тех записей, которые мы извлекали из практически любых устройств, оснащённых камерами. Тогда я не знал о том, что Linux имеет репутацию операционной системы, рассчитанной на серверы и на программистов. Чем больше задач я решал с помощью Linux, тем сильнее мне хотелось научиться управлять всеми свойствами этой ОС. В итоге я выяснил, что компьютер показывает всю свою мощь тогда, когда его пользователь способен говорить на его языке. Через несколько лет после перехода на Linux я уже писал скрипты для автоматического редактирования видео, для объединения аудиофайлов, для пакетного редактирования фотографий, и для решения любых задач, которые мне удавалось сформулировать, и для которых удавалось найти решение. Мне не потребовалось много времени на то, чтобы понять, почему программисты любят Linux. Но именно Linux научила меня любить программирование.



Оказалось, что Linux это отличная платформа для программистов, и для начинающих, и для опытных. Нельзя сказать, что Linux необходима для того, чтобы писать программы. Успешные разработчики пользуются самыми разными платформами. Но у Linux есть много такого, что она может предложить разработчикам. Кое о чём из этого я и хочу рассказать.

1. Логичность Linux


Linux построена вокруг идеи автоматизации. Основные приложения Linux совершенно осознанно сделаны такими, чтобы их можно было бы, как минимум, запустить из терминала, указав дополнительные опции. А часто их можно и полностью использовать тоже из терминала. Эту идею иногда ошибочно считают чем-то вроде примитивной модели организации вычислений, так как существует распространённое (и неправильное) мнение о том, что писать программы, работающие из терминала, это значит прилагать абсолютный минимума усилий к тому, чтобы получить работающее приложение. Это печальный результат непонимания того, как работает программный код, но многие из нас периодически страдают таким вот непониманием. Мы думаем, что больше это всегда лучше, поэтому приложение, содержащее 1000 строк кода должно быть в 100 раз лучше, чем приложение, содержащее 10 строк кода. Так? Но правда заключается в том, что, при прочих равных условиях, лучше выбрать приложение, отличающееся большей гибкостью, при этом то, из скольких строк кода оно состоит, значения не имеет.

В Linux решение некоей задачи вручную может занять, например, час. То же самое можно, воспользовавшись подходящими инструментами командной строки, сделать буквально за минуту, а возможно и за меньшее время, если прибегнуть к GNU Parallel. Для того чтобы к этому привыкнуть, нужно определённым образом изменить взгляд на то, как именно работают компьютеры, нужно научиться мыслить не так, как прежде. Например, если задача заключается в том, чтобы добавить к 30 PDF-файлам обложки, можно решить, что приемлемая последовательность действий будет выглядеть так:

  1. Открыть PDF-файл в редакторе.
  2. Открыть файл с обложкой.
  3. Присоединить PDF-файл к файлу с обложкой.
  4. Сохранить полученный документ в виде нового PDF-файла.
  5. Повторить эти действия при обработке остальных старых файлов (а вот новые файлы, полученные из старых, обрабатывать уже не нужно).

Эта последовательность действий вполне согласуется со здравым смыслом, и хотя в ней много неприятных повторений, она позволяет достичь цели. В Linux, правда, можно организовать работу гораздо разумнее. Процесс размышлений над этой задачей, учитывающий возможности Linux, похож на процесс размышлений над ручным способом решения задачи. А именно, всё начинается с поиска последовательности действий, необходимых для получения нужного результата. Проведя некоторые изыскания, можно узнать о команде pdftk-java, а потом выйти на простое решение:

$ pdftk A=cover.pdf B=document_1.pdf \cat A B \output doc+cover_1.pdf

После того, как удастся убедиться в работоспособности команды при обработке одного документа, надо будет вложить некоторое время в изучение утилит для обработки наборов данных. В ходе изучения можно обнаружить команду parallel:

$ find ~/docs/ -name "*.pdf" | \parallel pdftk A=cover.pdf B={} \cat A B \output {.}.cover.pdf

Тут представлен подход к размышлениям над задачами, несколько отличающийся от обычного, так как код, который мы пишем, обрабатывает данные не так, как мы привыкли. Обычно мы ограничены представлениями о последовательной ручной обработке данных. Но выход за границы старых представлений важен для того чтобы позже писать соответствующий код. А побочным полезным эффектом такого выхода является получение возможности писать более эффективные программы, чем раньше.

2. Возможности по управлению связями кода


Неважно, для какой платформы вы программируете, вводя в редакторе код. Всё сводится к тому, что программист плетёт сложную сеть из невидимых связей между множеством различных файлов. Практически во всех случаях, за исключением каких-то совсем уж экзотических, код, чтобы стать полноценной программой, обращается к заголовочным файлам и использует внешние библиотеки. Это происходит на всех платформах, но Linux подталкивает программиста к тому, чтобы он сам бы во всём этом разобрался, а не доверял бы заботу обо всём этом исключительно инструментам разработчика для некоей платформы.

Надо сказать, что нет ничего плохого в том, чтобы доверять инструментам разработчика решение задач по нахождению библиотек и по включению в состав программ внешних файлов. Это, наоборот, полезная возможность, наличие которой должно вызывать у программиста лишь чувство благодарности. Но если программист совершенно ничего не понимает в том, что происходит, ему будет гораздо сложнее взять управление всем этим на себя в том случае, если инструменты разработчика просто не будут знать о том, как справиться с некими проблемами.

Это имеет отношение не только к Linux, но и к другим платформам. В Linux можно писать код, который планируется запускать и в Linux, и в других операционных системах. Понимание того, как именно компилируется код, помогает программисту в достижении его целей.

Надо признать, подобным вещам нельзя научиться, просто пользуясь Linux. Можно счастливо писать код в хорошей IDE и никогда даже не задумываться о том, какая версия некоей библиотеки была установлена, или о том, где именно находятся какие-то заголовочные файлы. Но Linux ничего не скрывает от программиста. Очень просто углубиться в недра системы, найти в ней то, что нужно, и прочитать соответствующий код.

3. Удобство работы с существующим кодом


Полезно знать о том, где находятся заголовочные файлы и библиотеки, но возможность видеть их код это ещё один пример дополнительного преимущества программирования в Linux. В Linux можно посмотреть код практически всего, о чём можно подумать (за исключением приложений, работающих на Linux, но не являющихся опенсорсными). Невозможно переоценить полезность этой особенности Linux. По мере того, как некто всё лучше и лучше осваивает программирование в целом, или разбирается с чем-то новым для себя, он может многое узнать, читая существующий код в своей Linux-системе. Многие программисты научились делать своё дело, читая опенсорсный код других людей.

При работе с системами, код которых закрыт, можно найти документацию, ориентированную на разработчиков и содержащую примеры кода. Это хорошо, документация это важно, но это не сравнить с возможностью обнаружить именно тот функционал, который планируется реализовать, и с возможностью найти исходный код, демонстрирующий то, как это сделано в приложении, которым вы пользуетесь каждый день.

4. Прямой доступ к периферии


Я, после того, как разрабатывал на Linux программы для медиакомпаний, иногда принимаю как должное возможность доступа к периферийным устройствам. Например, при подключении к Linux-компьютеру видеокамеры можно загрузить входящие данные из /dev/video0 или из подобного устройства. Всё что нужно, можно найти в /dev, и это всегда кратчайший путь из точки A в точку B.

А вот на других платформах это не так. Подключение к системам, находящимся за пределами ОС это всегда лабиринт, построенный из SDK, библиотек с закрытым кодом, а иногда и из соглашений о конфиденциальности. Ситуация, конечно, не везде одинакова, она зависит от того, для какой именно платформы пишет код программист, но другим системам сложно поспорить с простотой и предсказуемостью интерфейса Linux.

5. Хорошо продуманные абстракции


Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.

Итоги


Есть гораздо больше причин того, что программировать в Linux это удовольствие. Некоторые из них представляют собой широкомасштабные концепции, некоторые мельчайшие детали, которые избавили меня от многих часов тяжких поисков решения неких задач. Linux это место, в котором приятно находиться, при этом неважно на какой именно платформе будет запускаться код, который пишут в Linux. Кем бы вы ни были человеком который только начал осваивать дело написания программ, или опытным кодером, который ищет себе новый цифровой дом, нет лучше места для программирования, чем Linux.

Какой ОС вы пользуетесь при написании программ?
Подробнее..

Запускаем DOOM на калькуляторе HP Prime G2

26.02.2021 16:11:32 | Автор: admin

Установить DOOM на какое либо устройство, это как водрузить знамя победителя на павшей крепости. Мне задали вопрос ну что, doom запустил? не менее 35 раз, когда узнали что я вожусь с данным калькулятором. Решил не разочаровывать публику и добиться запуска DOOM. Попутно, это стало неплохим тестом работоспособности оборудования, а также выявления неприятных багов. В общем, поехали!

Новости по проекту


Тем, кому интересно как же я запустил DOOM, могут пропустить эту главу и перейти сразу к следующей. Тут просто представлен текущий статус проекта.
Как вы помните в прошлых частях (часть 1 и часть 2), я занимался тем что ставил Linux на калькулятор, пересобирал u-boot, kernel, rootfs. С тех пор достаточно плотно занимался калькулятором и даже основательно разобрался с тем, что же было сделано в u-boot, kernel и device tree. Надо понимать, что это моё хобби, в свободное от основной работы и семьи время, поэтому не всё идёт быстро, и порой несколько алогично, просто потому что сегодня есть настроение делать так, а не иначе.
Главная новость состоялась, благодаря пользователю Alx2000y, который пригласил меня в чатик в телеге, где на аналогичном процессоре народ пилит свою прошивку для Xiaomi Gateway. Даже есть статья на хабре по теме. Народ уже сильно продвинулся в данной теме, невероятно расширив функционал устройства. И мне очень сильно помогли победить проблему nand. Как вы помните, в самом начале я свой образ nand затёр по глупости. В результате, у меня получилось достаточно большое количество виртуальных битых секторов, самое неприятное что битые сектора находились в самом начале и не давали записать туда u-boot. Ниже привожу список битых секторов, большинство из них виртуальные.

=> nand badDevice 0 bad blocks:  00000000  00020000  00040000  00060000  012c0000  04e20000  05280000  094c0000  17b20000  1ff80000  1ffa0000  1ffc0000  1ffe0000=> 

Ленар, из вышеупомянутого чатика, очень сильно мне помог, проблема решилась буквально двумя командами в u-boot:

nand erase.chipnand scrub.chipReally scrub this NAND flash? <y/N>y

После чего, проверяем количество битых секторов, и, о чудо, их стало значительно меньше!

=> nand badDevice 0 bad blocks:  1ff80000  1ffa0000  1ffc0000  1ffe0000

В результате, я теперь могу загрузить u-boot в нулевой сектор и произвести загрузку. На данный момент, калькулятор может быть загружен просто подав питание и будет полностью загружен linux, с работающим дисплеем и возможностью запуска программ по UART. Там даже корректно работает DOOM. Но, есть нюанс (С). Видимо драйвер клавиатуры как-то пересекается с драйвером ubifs, и в результате, если нажать любую клавишу на клавиатуре, то происходит мгновенное зависание калькулятора. Мне разок даже прилетел kernel panic, но я не сообразил его сохранить, чтобы хотя бы найти место этого пересечения. Так что на данный момент, всё однозначно работает в initramfs. Видео с демонстрацией работы загрузки nand, запуска DOOM и зависания постил в своём телеграмм канале.

Из других хороших новостей, попробовал поставить ubuntu на nand, тоже корректно работает. Пакеты, конечно, ставить нельзя, но в целом можно работать и использовать её, что тоже удобно. Но без работающий клавиатуры, эти игры пока лишены практического смысла.
В последней части я жаловался, что u-boot имеет разное поведение, при работе на nand и из ОЗУ. Я потратил два дня, ковыряния в исходных кодах u-boot, чтобы понять в чём же дело. А всё оказалось банально (даже стыдно). Утилита uuu, при запуске u-boot из памяти, передаёт туда свои переменные окружения. А точнее вызывает mfgtool_args и в результате строка переменной окружения загрузки выглядит таким образом:

bootargs=rdinit=/linuxrc g_mass_storage.stall=0 g_mass_storage.removable=1 g_mass_storage.file=/fat g_mass_storage.ro=1 g_mass_storage.idVendor=0x066F g_mass_storage.idProduct=0x37FF g_mass_storage.iSerialNumber= mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs) clk_ignore_unused

Разумеется, если загрузиться с nand, то с такими параметрами ubifs в четвёртом разделе виден не будет. Поэтому после загрузки u-boot в ОЗУ, я принудительно задаю ему следующие переменные окружения:

setenv bootargs  console=ttymxc0,115200 ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs)

И всё отлично работает.
Поясню, зачем это нужно: если прошить загрузчик в нулевой сектор, пропадает возможность работы через mfgtool (утилита uuu). А на данном этапе, состоящем из разработки и отладки это основной инструмент. Поэтому проще оставить возможность работы утилиты uuu, и загружать каждый раз u-boot вручную.

Запуск DOOM


Переходим к самой интересной части к запуску DOOM на калькуляторе. Как вы понимаете, я не зря вначале расписал обо всех проблемах. Можно запустить DOOM при загрузке на NAND-флеш, там можно поставить карты всех видов, все возможные версии DOOM и вообще всего что душа пожелает. Но при запуске в ОЗУ, мы ограничены размером образа rootfs примерно в 15 МБ (практика показала, что 16 ещё прокатывает). В связи с этим, пришлось подбирать версию DOOM и делать правильную сборку, а также научиться с ней работать.
Оказалось, что всё хорошее давно придумано за нас, и DOOM можно собрать прямо в buildroot не вставая с дивана. Это я узнал, когда гуглил все возможные варианты DOOM для встраиваемых систем и пытался их собрать. Как оказалось, достаточно запустить:

make menuconfig

И выбрать DOOM. Это делается в "Target packages ---> Games --->"


В нашем распоряжении две версии DOOM: chocolate-doom и prboom. После нескольких экспериментов, я понял что chocolate-doom ну никак не хочет влезать в initramfs. Разве, если вообще убрать wad-файлы. Пытался найти обрезанные wad-файлы, которые бы влезали вместе с шоколадным думом. Но она с ними на отрез отказалась работать. В результате, я попробовал шоколадную версию установить на nand (вместе с prboom), и пробовал там. Подбирал параметры и т.д. Результатом экспериментом стала следующий способ запуска:

export SDL_NOMOUSE=1 chocolate-doom -geometry 320x240 -bpp 24 -nomouse

Итог меня сильно разочаровал: эта версия doom некорректно (или может наоборот корректно) растягивает экран, оставляя широкие полосы по краям экрана, что мне очень не понравилось.


Шоколадная версия DOOM. Видна чёрная полоса снизу.

При запуске, мне шоколадный дум говорит о том, что делает изменение размера окна:

I_InitGraphics: 320x240 mode not supported on this machine.I_InitGraphics: Auto-adjusted to 320x200x32bpp.

Поэтому, я остановился на prboom. Сделал образ вместе с шароварными WAD-файлами и самим prboom, всё лишнее убрал. Но, всё равно очень долго не мог заставить его работать. Читал всевозможные мануалы, искал как сконфигурировать, чтобы всё корректно работало. Изображение выводит, на кнопки реагирует, но экран коряво растягивает и выводит кривые цвета. Пока на каком-то форуме не нашёл идеальные параметры запуска.
В общем, для нашего калькулятора запуск prboom такой: отключаем мышку, и далее запускаем prboom со следующими параметрами:

export SDL_NOMOUSE=1 /usr/games/prboom -width 320 -height 240 -nosound -vidmode 32bit

Ключевой параметр здесь: "-vidmode 32bit".


Долго искал подходящие параметры, и только с этим всё завелось. Для удобства всё записал в скрипт d.sh. Наконец всё работает, можно даже играть!


Специально для вас, я подготовил обновлённую сборку flash_utility с DOOM, который вы можете запустить на своём калькуляторе даже без перепрошивки, и показать друзьям, мол вот, DOOM у меня в калькуляторе работает. Достаточно разобрать калькулятор, замкнуть контакты, описанные в первой части и запустить

sudo uuu doom.uu

В конце всех действий, вы получите калькулятор, с linux и DOOM. Чтобы запустить DOOM, надо будет залогиниться и на калькуляторе выполнить:

./d.sh

Резюмируя


DOOM работает! Можно ли в него играть? Ну локально, загружая с компьютера можно. Это выглядит круто и красиво, но на деле, не совсем то что хочется получить. В действительности будет круто, когда ты едешь в метро, взять и достать из широких штанин калькулятор, включить его (на данный момент режим энергосбережения не работает), и запустить DOOM. Вот это реально круто, играть в метро на калькуляторе в DOOM, Duke Nukem 3D, Quake I, II, III и т.д. Но факт остаётся фактом DOOM на этой железке запущен. Но ещё очень много работы.
В целом, не хватает хотя бы небольшого сообщества вокруг этого калькулятора (хотя бы больше меня одного), чтобы были тестировщики проблем, было с кем поговорить и поделиться, услышать совет. Первоначальный автор явно остыл к данному проекту, хотя и проделал титаническую работу. Я его хорошо понимаю, и никак не могу укорять за то, что он не хочет помогать даже советом по данному проекту. Ну так, небольшие рекомендации давал, но ему явно уже не до него. Поэтому если у вас есть идеи, калькулятор, желание помочь, хотя бы советом, пишите тут или в телегу, буду рад!

P.S. Зачем я этим занимаюсь?


Очень часто спрашивают меня нафига? Умом понимаю, что на данный вопрос отвечать глупо, но тем не менее отвечу.
Зачем художник рисует картину или автор пишет книгу? Будем честны, 90% книг, картин да и других произведений могут вообще не увидеть свет, а из тех кто увидят, доли процента станут известными и обретут широкий круг читателей. Проще говоря, большинство творцов делают бесполезный труд. Более того, множество произведений даже никогда не находят своего читателя, но что же им этого не делать? Что движет этими людьми? Всё достаточно банально. Ими движет простое чувство:


Проще говоря, этим занимаешься, потому что это круто и это прёт. И, как это ни странно, в будущем приносит большую пользу, хоть и не такую явную как кажется.

Файлы для скачивания




Подробнее..

Перевод PowerShell это язык программирования?

27.02.2021 12:14:40 | Автор: admin
Является ли PowerShell языком программирования? Совершенно определённо является. И не обращайте внимание на тех, кто говорит, что это не так. Многие, работающие в сфере программирования, могут просто посмеяться над мыслью о том, что код, написанный для PowerShell это нечто большее, чем обычные скрипты. Такие люди категорически неправы. Здесь мы поговорим о том, почему это так. Но если вы читаете этот текст в поиске чёткого ответа, то знайте PowerShell это язык программирования. Более того, PowerShell это поразительный инструмент, который позволяет решать практически любые задачи. С помощью PowerShell можно сделать что-то простое, такое, что обычно делают в командной строке Windows (CMD), а можно, используя Windows Forms, построить полномасштабное приложение. Границы того, что можно создать с помощью PowerShell, ограничены лишь фантазией разработчика и его навыками поиска в интернете.



Здесь мы пройдёмся по некоторым вопросам о PowerShell, которые возникают у людей чаще всего. Особое внимание мы уделим вопросу о том, можно ли считать PowerShell языком программирования. Я работал с PowerShell много лет, но не могу сказать, что освоил хотя бы малую часть возможностей этой системы. Поэтому я, приступая к работе над этим материалом, уверен в том, что и я, и тот, кто будет этот материал читать, узнаем много нового об этом фантастическом инструменте. Ну и, конечно, я надеюсь, что мне удастся чётко ответить на вопрос о том, является ли PowerShell языком программирования.

Зачем вообще учиться программировать?


Я полагаю, что в заголовок этого раздела вынесен хороший вопрос. Зачем учиться программировать? Ведь это очень сложно, а полученные знания и навыки, вероятно, не пригодятся IT-специалисту в обычной работе. Тот, кто думает, что так оно и есть, глубоко ошибается. В наши дни научиться программировать как никогда просто, при этом конкретная сфера деятельности того, кто учится программировать, особой роли не играет.

Благодаря поисковику Google и видеохостингу YouTube (это, соответственно, первый и второй по посещаемости сайты в мире) в нашем распоряжении имеются нескончаемые запасы бесплатных и хорошо подготовленных учебных материалов. Если тому, кто хочет изучить некий язык программирования, попадётся хороший курс, то он меньше чем за час (в буквальном смысле) сможет настроить среду разработки и написать свой первый Hello World. На следующем рисунке можно видеть Hello World на PowerShell.


Hello World на PowerShell это очень просто

Может, изучая программирование, вы подумываете о продвижении по карьерной лестнице и считаете, что знания из сферы DevOps это как раз то, что вам нужно. Ведущие языки программирования для DevOps это Golang, Python, Ruby, C# Данный список можно продолжать и продолжать (и в этот список, пожалуй, можно включить практически все актуальные языки программирования).

Есть масса причин для того чтобы учиться тому, как писать программы. Может, кому-то всегда хотелось сделать веб-приложение для организации, где он работает. А может кто-то мечтает написать успешную мобильную игру, которая обеспечит его на всю оставшуюся жизнь. Возможно, что кому-то просто хотелось бы автоматизировать свои рутинные задачи и высвободить время, которое он, быстрее справляясь со своими обязанностями, сможет потратить на просмотр видео с котами. Умение программировать делает всё это возможным.

Что такое язык программирования?


Прежде чем называть PowerShell языком программирования или средой для разработки скриптов, нам, вероятно, надо сначала разобраться с тем, что такое язык программирования. Если говорить простыми словами, то язык программирования это последовательность наборов инструкций, которые взаимодействуют с компьютерной системой.

Эти инструкции можно воспринимать как способ объяснения компьютеру того, чего от него хочет человек. При этом такой способ, который не требует от человека изучения ассемблера или низкоуровневого программирования в машинных кодах с использованием шестнадцатеричных и двоичных конструкций (правда, кое-кто свободно владеет подобными методами общения с компьютерами; мы выражаем таким людям своё почтение!).

Существуют разные виды языков программирования. Кратко опишем их:

  • Процедурные языки программирования. В них код выполняется линейно и пошагово. Это означает, что если некто создал приложение, то код этого приложения должен выполниться от начала до конца, после чего его работа завершается. А если при выполнении этого кода возникнут какие-то проблемы его выполнение должно быть прервано.
  • Функциональные языки программирования. Тут используются символические представления вычислений. В таких языках применяются конструкции, которые не особенно сильно отличаются от математических функций.
  • Объектно-ориентированные языки программирования. В этих языках типы данных могут содержать как данные, в форме атрибутов и свойств объектов, так и функции, манипулирующие этими данными.
  • Скриптовые языки программирования. Для запуска кода, написанного на таких языках, не нужен компилятор. Они используют так называемые интерпретаторы. При написании программ на этих языках применяются предварительно подготовленные команды и функции, хотя подход к созданию программ на таких языках похож на подход, используемый при работе со стандартными языками.
  • Логические языки программирования. В логических языках программирования используются (вот уж неожиданность) правила логики. Они позволяют, оперируя фактами и заданными правилами, автоматически выводить результат.

Тут, конечно, языки программирования охарактеризованы очень сжато, но я полагаю, что мы, во-первых, перечислили самые популярные виды языков программирования, а во-вторых, в общих чертах описали их суть. А теперь давайте разберёмся с тем, что такое PowerShell, и с тем, является ли PowerShell языком программирования.

Суть PowerShell


До PowerShell в мире Microsoft Windows существовал VBScript. Используя этот язык программирования можно решить очень большое количество задач, но в наше время, в 2021 году, вероятно, это количество примерно равно количеству задач, нерешаемых с помощью VBScript. Инструмент PowerShell создавался как средство, которое поможет использовать всё лучшее, что есть в платформе .NET, и при этом будет иметь доступ ко встроенным возможностям ОС. Джеффри Сновер, человек, который придумал PowerShell, на самом деле, очень подробно об этом рассказывает в работе Monad Manifesto, которую он написал в 2002 году. Это захватывающее чтение, в этом материале чётко выражено его видение проекта, который в итоге и стал тем, что получило название PowerShell.

Проект PowerShell, с момента его появления, почти 20 лет стремительно развивался. То, что проект этот достиг уровня зрелости, очевидно для всех, кто им пользуется, и кто полагается на него в решении своих ежедневных задач, вне зависимости от того, что именно это за задачи. Существует обширный набор так называемых командлетов, которые поддерживаются их создателями в актуальном состоянии и дают тому, кому это нужно, постоянно пополняемый набор гибких и мощных инструментов.

И всё же, PowerShell это язык программирования или нет?


Можно ли отнести PowerShell к какому-то из вышеописанных видов языков программирования? Возможно, вы уже пришли к выводу о том, что PowerShell, на самом деле, подпадает под несколько категорий языков программирования. Пуристы отвергнут идею о том, что PowerShell это полноправный язык программирования, и я даже вижу причину такого видения ситуации.

PowerShell полагается на системные хуки ОС Windows для выполнения множества встроенных команд, или, как их называют в PowerShell-сообществе, командлетов (так что этот термин придумал не я). Каждый из командлетов способен выполнить некую очень полезную, или, в некоторых случаях, очень мощную операцию.

В PowerShell для организации обмена переменными и данными используются объекты. Поэтому можно сказать, что тут используются идеи, роднящие PowerShell с объектно-ориентированными языками программирования. Многие считают PowerShell скриптовым языком программирования. А это, что невозможно не признать, во многих отношениях так и есть. Но PowerShell-код может работать и как код обычных приложений. Этот код, как и программы, написанные на том же Python, или на ещё каком-то распространённом языке, может включать в себя циклы, вроде foreach и while, условные конструкции и многое другое.

Всё это позволяет создавать весьма мощные приложения, которые могут быть запущены в Windows с помощью планировщика заданий, могут быть, ради упрощения их выполнения, преобразованы в .EXE-файлы, могут быть запущены в фоне, в виде служб Windows. Я регулярно пользуюсь всеми этими методами работы с PowerShell-скриптами и могу с уверенностью заявить о том, что они избавили меня от месяцев ручного труда и помогли мне оставаться на хорошем счету у начальства и коллег. Я, правда, шучу, никто этого не замечает, но я-то всё это вижу.

Если говорить серьёзнее, то PowerShell может оказать компьютерщику огромную помощь, и речь идёт не только о решении рабочих задач. Например, я хочу написать цикл материалов о том, как я создал простое Windows Form-приложение для моей мамы, которой уже за 70. Это приложение позволяет ей переключать настройки почтового сервера в путешествиях (до того, как мир охватило то, что происходит сейчас) буквально несколькими щелчками мыши.

Я надеюсь, что этот небольшой проект вдохновит на создание чего-то похожего тех, кто никогда ничего такого делать не пытался, и что процесс создания своего проекта принесёт им много положительных эмоций. Поэтому, если вам это интересно, можете иногда заглядывать в список моих публикаций. А вот материал о том, как узнать версию PowerShell в Windows 10.

Полагаю, мы справились с нашей задачей. Мы выяснили, что PowerShell это язык программирования, но вряд ли он будет основным языком, на котором пишет некий программист. Высоки шансы того, что тот, кто недавно узнал о PowerShell, воспользуется несколькими мощными скриптами для решения неких задач бэкенда своего приложения. Но реальность такова, что у скомпилированных приложений, запускающихся в операционной системе, есть преимущества в производительности перед хуками, используемыми в командной оболочке ОС Windows.

Итоги


Надеюсь, вы вынесли что-то полезное из этой нашей небольшой вылазки в мир языков программирования. Я не считаю себя экспертом ни в одной из тех областей, которых коснулся в этом материале. Я энтузиаст, который хочет учиться новому. Я думаю, что главное, что можно вынести из чего-то вроде изучения программирования, скриптов, автоматизации, это желание осваивать новые навыки и развиваться.

Это тот сорт любознательности, который, в итоге, поможет своему обладателю больше узнать о системах, с которыми он работает, поможет создать для этих систем что-то полезное, такое, что облегчит ему решение его повседневных задач. А если снова вернуться к вопросу о том, является ли PowerShell языком программирования, то я полагаю, что на этот вопрос совершенно спокойно можно ответить утвердительно.

Какие задачи вы решаете с помощью PowerShell?

Подробнее..

За что IT-компании платят экономистам и сколько стоит человеческая жизнь?

27.02.2021 16:15:57 | Автор: admin

На этой неделе наших соцсетях выступал Евгений Канашевский, экономист из Zalando, Economics Phd университета Штата Пенсильвания.

На работе Женя занимается установлением причинно-следственных связей в онлайн-рекламе с помощью экспериментальных и квазиэкспериментальных методов и моделей машинного обучения.

Делимся с вами расшифровкой эфира.



Меня зовут Евгений Канашевский. Сегодня мы поговорим о том, за что IT-компании платят экономистам, о том, чем экономисты отличаются от обычных data scientist-ов, и ответим на интересные вопросы вроде сколько стоит человеческая жизнь?, которыми занимаются экономисты.

Для начала я представлю себя. Я сейчас работаю экономистом/data scientist-ом в большой компании Zalando. Это онлайн-магазин, который продает одежду, обувь, косметику в 16 странах Европы и планирует расширение на новые рынки. До того, как я присоединился к Zalando в 2020 году, я делал PhD по экономике в университете штата Пенсильвания. Я начал интересоваться экономикой задолго до этого, когда учился в МФТИ и потом также в Российской экономической школе.

До того, как поехать на PhD по экономике, я работал 2 года в агентстве контекстной рекламы в Москве; очень сильно хотел узнать больше о том, что такое экономика и как она устроена. Чтобы утолить свою жажду, я поехал в итоге на PhD. Сейчас я надеюсь поделиться с вами этим знанием. Надеюсь, вам будет интересно, и мы поймем, зачем бизнесу экономисты.

Для начала попробуем развенчать некоторые устоявшиеся представления об экономистах, которые, исходя из моего опыта, присутствуют в России. Многие из вас, наверно, брали курсы экономики в университете, и вы помните, что проходили рыночное равновесие, кривые спроса и предложения. Кто-то из вас, может быть, проходил макроэкономический баланс разного рода из чего состоит ВВП, как считать его, что будет с ВВП в случае, если государство потратит столько-то денег, какие налоги собираются с населения. На такие вопросы вы, возможно, отвечали на курсах экономики в университете, и немногие из нас продвигались дальше.

Устоявшееся мнение об экономистах состоит в том, что они работают в научных институтах (РЭШ, ВШЭ) или международных организациях (МВФ, Мировой банк, Организация экономического содействия и развития), и там они помогают странам вырваться из ловушки бедности и провести экономические реформы. Они могут работать в государственных организациях центральных банках, министерствах экономического развития своих стран. Если они супер-амбициозны, то они могут попробовать стать экономическим советником президента США. Стереотипное представление об экономистах в индустрии состоит в том, что в индустрии они работают в банковской сфере и в финансовой сфере.

Я часто встречал такое дефолтное представление об экономистах что они занимаются только этими вещами. На самом деле, экономическая наука гораздо шире. Она занимается самыми разными интересными вопросами, связанными с людьми, и поэтому бизнесы нанимают их.
Давайте посмотрим, какие вопросы задают экономисты. На эти вопросы даются ответы, по ним читаются лекции на курсах экономики, в бакалавриате.

Один из фундаментальных вопросов, на которые ищут ответы экономисты, звучит так: Почему одни страны богатые, а другие бедные. Это вопрос вида что было раньше яйцо или курица? Что было раньше: экономический рост или демократические институты? Страны англосаксонского мира такие богатые, потому что они установили у себя демократические институты (разделение властей, независимая законодательная власть, независимая судебная система, отделенные от исполнительной власти) и поэтому стали такими богатыми впоследствии, смогли расти экономически? Или все наоборот: эти страны росли экономически, и потом, став богатыми, решили установить у себя демократические институты? Это нетривиальный вопрос, на него очень сложно ответить. Этот вопрос существенен для многих стран: например, Китай это страна, чья экономика растет очень быстро. Сможет ли она расти дальше теми же темпами, и нужны ли Китаю эти самые демократические институты, либо Китай сможет продолжать расти в достаточно недемократичной среде?

Этот вопрос был актуален и раньше. В первой половине XX века СССР развивался очень быстро, возможно, быстрее, чем страны западного мира. Экономисты задавались вопросом сможет ли СССР расти так и дальше, этот вопрос был крайне важен стратегически во время Холодной войны. Дальнейшая история показала, что СССР не смог продолжать свое экономическое развитие, и консенсус среди экономистов состоит в том, что это было невозможно из-за отсутствия демократических институтов и рыночных механизмов экономики.

Такими вопросами задаются экономисты. Эти вопросы сложны, потому что в мире не так уж и много стран; невозможно заглянуть в параллельную вселенную, где СССР развивался бы с применением рыночных механизмов экономики и демократических институтов. Помимо вопросов в глобальном масштабе, экономисты задаются и более повседневными вопросами, которые имеют хорошую практическую ценность. Например как выгодно продать радиочастоты в нескольких штатах США. Представьте себе: вы владеете определенным диапазоном радиочастот (вы представляете государство). Вы хотите продать их наиболее выгодным способом так, чтобы максимально принести денег в бюджет. Возникает вопрос: как устроить механизм, с помощью которого вы будете это делать? Экономисты предлагают использовать аукционы, чтобы продавать частоты; это кажется логичным, если вспомнить, как продаются произведения искусства, например. Но тогда возникает следующий вопрос: как оптимально устроить аукцион, чтобы получить в бюджет максимально много денег?

Это звучит абстрактно но подумайте, например, о таких явлениях, как сговор. Покупатели на аукционе могут сговориться у вас за спиной и сказать: давай я куплю эти частоты, а ты эти, и ты поставишь низкую ставку на одни диапазоны, а я на другие. И тогда они заплатят как можно меньше. Задача экономистов в том, чтобы не допускать таких сговоров и обеспечивать государству как можно больше денег в бюджет, который будет использован на благо граждан.

Другой пример интересного вопроса, которым задаются экономисты: Как устроить рынок пересадки почек, чтобы спасти как можно больше людей? Слово рынок здесь звучит не очень хорошо с моральной точки зрения, если вы не экономист; скорее всего, это слово здесь ассоциируется у вас с нелегальным рынком, с продажей почек, что является преступлением. Но, когда я сейчас говорю о рынке, я имею в виду то, что существует спрос на почки: есть люди, которым нужны почки, и есть люди, которые готовы предложить свою почку потому что человек может нормально жить с одной почкой.

Представьте гипотетическую ситуацию: вашей жене (мужу, девушке, парню, родителю) нужна почка, и вы готовы ее отдать. Но дело в том, что необходима совместимость. Вашему близкому человеку может просто не подойти ваша собственная почка. Что можно сделать: можно найти такую же пару людей (может быть, из другого города, региона или страны), которые несовместимы между собой, но при этом ваша почка может подойти нуждающемуся человеку из другой пары и наоборот. И таким образом у двух людей, у которых раньше не было шансов получить почку, либо им нужно было ждать очень длинной очереди на почку (а это может длиться месяцы или годы), появляется этот шанс благодаря тому, что мы нашли две пары, готовые обменяться почками, на этом рынке почек. Мы помогли людям.

Конечно, ситуация может быть гораздо сложнее. Может быть, вам придется провернуть цепочку из очень многих ходов привлечь очень много пар людей, в которых, когда они все вместе, получится найти такие обмены, чтобы все нуждающиеся люди из этих пар получили почку. Необязательно только две пары. Можно представить пример с тремя парами: почка здорового человека из одной пары подходит нуждающемуся человеку из следующей пары и так далее. Такие циклы могут доходить до 70 пар, на самом деле. Это пример случая, в котором экономисты разработали алгоритм для того, чтобы организовать рынок и помочь людям с пересадкой почек. За это была получена Нобелевская премия по экономике в 2012 году профессором Стэнфордского университета Элом Ротом.

Еще один интересный вопрос, который не совсем очевиден с моральной точки зрения сколько стоит человеческая жизнь. Непонятно с моральной точки зрения, как можно ее вообще оценивать ведь человеческая жизнь бесценна. Но мы можем подумать как экономисты прагматично и практически, где нам может понадобиться оценка человеческой жизни.

Представьте, что вы хотите потратить деньги на улучшение дорог в России. Каждый год на дорогах погибает 15 тысяч человек, примерно. Вы думаете, сколько вы готовы инвестировать в улучшение дорог с точки зрения государства. Хороший способ думать об этом это сколько человеческих жизней спасет такое улучшение дорог. Для хорошей оценки издержек на построение дорог и пользы, которую можно получить от построения дорог, нужна как раз цена человеческой жизни.

Это оценки были сделаны; они были сделаны для США, потому что там есть хорошие данные на самом разном уровне. Эти оценки говорят, что цена человеческой жизни колеблется в диапазоне от 4 до 9 миллионов долларов. Такие оценки, конечно, нужно проецировать на Россию мы должны измерить, как цена человеческой жизни отличается в странах, где люди меньше зарабатывают и приносят меньше ценности. Это очень грубый подсчет, но есть правила пересчета. И, как это ни грубо звучит, цена человеческой жизни в России меньше, чем в Америке, просто из-за того, что экономика в России менее производительна. Но, тем не менее, можно получить какие-то оценки и с помощью этого решать практические вопросы например, сколько мы готовы тратить на улучшение безопасности на дорогах, чтобы терять меньше людей.

Итак, надеюсь, примерно стало понятно: экономисты занимаются самыми разными вопросами, но общее в этих вопросах то, что мы везде изучаем не предметы материального мира (как физики, например), а живых людей. Экономисты изучают стимулы людей как устроены люди, какие решения они принимают.

Где работают экономисты помимо международных организаций, научных институтов, госорганизаций и банков? Экономисты работают в отраслевом консалтинге, в основном в разных консалтинговых фирмах. Все больше и больше работают в больших и не очень больших IT-компаниях. Просто чтобы назвать пример самых больших компаний это Google, Amazon, Uber, Facebook; компания, в которой работаю я (Zalando) это e-commerce-компания, у которой есть собственная команда экономистов для решения задач о поведении людей. Netflix пример компании, не очень большой по штату сотрудников, которая при этом нанимает экономистов, которые решают очень интересные задачи.

Рынок компаний, которые нанимают экономистов, не ограничивается этими примерами. Но большие компании, которые нанимают много людей в принципе, нанимают все больше и больше экономистов.

Тогда вопрос: зачем IT-бизнесы нанимают экономистов? Односложный ответ чтобы предложить клиенту ценность. То есть, мы исходим из того, что бизнесы хотят предложить клиенту ценность, и для этого они должны понять, как принимают решения клиенты (если обобщить как это делают люди). Это то, чем экономисты занимаются на протяжении последних 100 лет, как минимум. Они изучают то, как люди принимают решения в самых разных ситуациях. Не только на классических рынках, о которых вы можете подумать из вводных курсов экономики, которые у вас были, но и на самых различных рынках и в самых разных ситуациях.

Чтобы ответить более детально на вопрос почему IT-фирмы набирают именно экономистов, разберем три пункта. Во-первых, почему экономисты исследуют, как принимают решения люди в самых разных ситуациях как так получилось, что они этим занимаются и задают странные вопросы (какова ценность человеческой жизни?, как устроить рынок пересадки почек?). Во-вторых, мы разберем 4 вида задач, для которых бизнесу нужны экономисты. И, наконец, мы обсудим, почему бизнесу нужны именно экономисты, а не обычные data scientist-ы: в чем различия между ними.

Пункт первый: почему экономисты отвечают на вопросы о поведении людей? Здесь не помешает немного истории. Экономисты начали изучать рыночное равновесие еще в XVIII веке (как минимум). Они начали задавать вопросы: как устроены рынки, как формируется спрос, как устроено предложение. Они думали о классических рынках давайте представим рынок хлопка или зерна, например. Это не было связано с такими безумными вопросами вроде ценности человеческой жизни. Однако в этих классических рынках равновесие равновесная цена, количество проданных товаров зависело от решений, принимаемых людьми, и от того, какими стимулами руководствуются люди при покупке и продаже товаров. Когда экономисты изучали рыночное равновесие, то для того, чтобы лучше давать ответы на возникающие вопросы, им приходилось разрабатывать достаточно продвинутые математические методы. К XX веку экономисты и математики разрабатывали математические методы для ответов на вопросы, связанные с рыночным равновесием.

Может быть, вы смотрели фильм Игры разума это отличный пример. Это фильм про Джона Нэша, математика, который получил Нобелевскую премию по экономике за свои статьи по теории игр. Она является исходно математическим концептом, но экономисты применяют очень активно наработки Нэша и других математиков и вообще, очень продвинутую математику в изучении рынка. Отчасти поэтому и получилось так, что экономисты способны решать сложные и странные вопросы.

В начале XX века статистика абстрагировалась от изучения причинно-следственных связей. Статистика умышленно стала заботиться лишь о распределениях данных, об условных распределениях, о том, как устроены данные, о том, как, зная одну переменную, предсказать другую (т.е. сказать, какова вероятность того, что случится одно событие при наблюдении другого события). Статистика абстрагировалась от таких вопросов, как как влияет наличие демократических институтов на экономический рост в стране в следующие 100 лет? или в одной стране люди выращивают сельхозкультуры, у которых очень большой размер плантации, и поэтому их выгодно обрабатывать подневольным трудом как рост в этой стране будет отличаться от роста в тех странах, где выращиваются другие культуры например, зерновые с меньшим размером плантации, из-за чего в этих странах много фермеров, а рабовладельческий труд в них был бы не так выгоден, как на плантациях риса или сахарного тростника; как эти факты повлияют на экономический рост в будущем этих стран? (под влиянием понимается причинно-следственная связь).

Экономистам пришлось разрабатывать собственные методы эконометрические методы для ответов именно на вопросы причины и следствие, а не простые вопросы о корреляциях или условных вероятностях. Это произошло в начале XX века. Мы перематываем в последнюю четверть века и понимаем, что экономисты, начиная с XVIII века, разрабатывали математические методы, строгую математику; экономисты, начиная как минимум с XX века, разрабатывали сложные статистические методы, которые помогают более уверенно ответить на вопросы причины и следствия. И мы понимаем, что экономика это та наука, которая помогает ответить на вопросы о поведении людей, и сделать это максимально строго используя максимально высокие стандарты установления причинно-следственной связи.

Чем особенно поведение людей и его изучение? Дело в том, что здесь мы не можем поставить эксперимент. Мы не можем клонировать человека и проверить, что бы случилось с точно таким же человеком, который поступил бы в другой университет, например, и получил менее качественное образование как бы это повлияло на его заработок в будущем. Поэтому экономистам пришлось разрабатывать математические и статистические методы, чтобы понять, как именно решения людей влияют на их будущее и на то, что с ними произойдет.

Это подводит нас к тому, почему IT-компании нанимают экономистов. Я выделил 4 большие области, где работают экономисты в IT-компаниях; это не полный список экономисты занимаются и другими вещами, но эти области уже сформировались.

Первая область оценка спроса на товары или услуги. Здесь можно подумать о многих бизнесах, но я приведу самые яркие примеры. Amazon один из крупнейших онлайн-магазинов (не могу сказать, кто самый крупный Amazon или Alibaba), огромная компания с огромным штатом, которой очень важно оценивать спрос: сколько товаров будет продано, как изменение цен повлияет на продажи. Uber рай для экономистов, потому что у него очень много данных: можно оценивать спрос на такси, можно отвечать на вопросы типа как установить цены на Uber в час пик в центре Манхэттена, как эти цены должны отличаться от цен в другое время в этом же месте; как сделать так, чтобы Uber получил выручку, и при этом люди могли заказать такси и такси к ним приехало. То есть, мы видим, что здесь много людей, и у них разные стимулы: у клиента стимул как можно быстрее и дешевле поехать на такси, Uber и таксист хотят заработать денег.

Второй пример задачи это аукционы. Здесь самые яркие примеры это Google и Yandex, рынки онлайн-рекламы. Каждый раз, когда вы вбиваете в поиск что-либо, проводится маленький аукцион, и кто-то платит за то, чтобы показать вам рекламу. От 70 до 90% выручки материнской компании Google Alphabet приходится на эти аукционы, то есть, Google живет за счет рекламы (Yandex тоже). Экономисты работают над тем, как спроектировать эти аукционы таким образом, чтобы бизнесы не тратили на рекламу лишние деньги, а пользователи получали релевантную рекламу. Все эти стимулы учитываются в проектировании аукционов экономистами.
Третий пласт задач это эксперименты и квазиэксперименты (A/B-тесты). A/B-тестирование проводится рутинно, постоянно в больших компаниях. Экономисты здесь занимаются проектированием систем для A/B-тестирования; на самом деле, провести его легко, сложно сделать это хорошо. Как правильно провести A/B-тестирование, подсчитать результаты, затратить минимум ресурсов и получить максимальную выгоду этим всем занимаются экономисты в таких компаниях, как Google, Facebook или Zalando. Компания Netflix хорошо известна своей платформой для экспериментов и A/B-тестов.

Четвертый пласт это измерение downstream impact: как продукт влияет на, допустим, lifetime value, которые вы получаете от одного клиента. Представьте, что вы хотите оценить, сколько должен стоить подписочный сервис вроде Amazon Prime: какую цену просить у подписчиков, чтобы максимизировать количество подписок, чтобы люди не отписывались? Для этого нужно оценить, сколько ценности Amazon Prime приносит клиенту не за день или месяц, а годами. И такие задачи, когда есть долгосрочное планирование и прогнозирование, долгосрочная оценка, решают экономисты для бизнеса.

Мы видим эти задачи, и вроде бы все хорошо, но возникает вопрос: чем экономисты отличаются от обычных data scientist-ов, ведь они тоже решают похожие задачи? Почему экономисты особенные, в чем их сравнительное преимущество? Объясним на примере лестницы причинно-следственных связей (ladder of causality). У нее три уровня. На примере трех вопросов в контексте оффлайн-магазина я попытаюсь объяснить, почему бизнесу нужны экономисты.

Представьте, что вы владелец обыкновенного магазина на углу, и вы хотите предсказать спрос на пиво и чипсы. Вы хотите пополнить запас товаров для продажи на следующую неделю для этого нужно предсказание спроса. Представим первый случай: следующая неделя не отличается существенно от предыдущей. Тогда на основании истории предыдущих покупок мы сможем построить модель, которая предсказывает спрос на чипсы и пиво на следующую неделю. Вопрос, который вы задаете, таков: сколько пива и чипсов люди купят при текущих ценах в нашем магазине, или в других похожих магазинах? Здесь очень важно словосочетание при текущих ценах то есть, мы смотрим на статус-кво.

Это мы назовем вопросом первого уровня: нам не важно, почему спрос на товары был именно таким на прошлой неделе. Хорошая предсказательная модель, которую мы будем строить, не обязана давать объяснения того, почему люди покупали столько пива и чипсов она должна на основе прошлых данных предсказать будущее с достаточной точностью. Примеры таких моделей: распознавание визуальных образов (отличить кошку от собаки на фото), определение спам-сообщений в e-mail, определение кредитного рейтинга потенциального клиента. В предсказательных моделях не важны причинно-следственные связи; основываясь на данных, которые у вас уже есть, вы хотите сделать предсказание для нового объекта картинки, сообщения, клиента. Здесь методы машинного обучения замечательно работают. Мы можем обучить продвинутые методы и сделать очень хорошее предсказание.

Перейдем ко второму вопросу и второму уровню лестницы. Допустим, мы захотели изменить цену на пиво на следующую неделю. Вопрос, который мы задаем, звучит так: что произойдет на следующей неделе с продажами пива, если поднять цену? А что произойдет с продажами чипсов, которые, возможно, связаны с продажами пива? Почему мы не можем просто использовать случаи из прошлого, когда в прошлом менялась цена на пиво? Именно потому, что, возможно, в прошлом цена менялась по другим причинам. Сейчас мы хотим сами поднять цену; в прошлом, может быть, все магазины автоматически подняли ее одновременно, из-за изменения акцизов. Или это могло случиться по иным причинам. Но предсказательная модель не способна знать этих причин, и здесь мы не можем просто методом машинного обучения подкрутить цену на пиво, увеличить ее как-то и предсказать, что будет с продажами пива и чипсов. Модели машинного обучения не работают в терминах причин и следствий. Они просто видят корреляции, которые были в данных в прошлом, и видят условные вероятности: например, вероятность того, что человек купит чипсы, если он уже купил пиво.

Что делать в таком случае? Мы можем провести эксперимент. Мы можем поднять цену на пиво лишь в отдельном магазине нашей сети (предположим, у нас имеется сеть магазинов) и посмотреть, что в этом магазине произойдет на следующей неделе с продажами пива и чипсов и в других магазинах тоже. Здесь мы проводим простейший A/B-тест. Как его правильно провести именно такими задачами задаются экономисты в компаниях. Это второй уровень вопросов по причинно-следственным связям. Здесь, в отличие от первого уровня, мы хотим узнать, что произойдет, если мы внесем изменение то есть, мы можем пощупать причину и следствие, изменение, которое мы вносим, и конечный результат (продажи пива и чипсов).

Третий уровень еще сложнее. Допустим, мы подняли цены на пиво и видим, что упали продажи чипсов. Почему упали продажи чипсов? Потому ли, что пиво стало дороже или, может быть, потому, что мы теперь продаем кукурузные палочки дешевле, чем чипсы? Вот мы взяли, не подумали и изменили цену на палочки. Или мы просто не можем контролировать все: у нас есть и кальмары, и фисташки, и кукурузные палочки, и цена на них тоже меняется. Нам сложно провести эксперимент, подобный эксперименту из второго уровня: меняются цены на очень много товаров, какие-то из них заменяют, какие-то дополняют чипсы (как пиво). И тогда перед нами стоит такой вопрос: Что бы случилось с продажами чипсов на этой неделе, если бы мы не изменяли цены на пиво? Тут мы хотим понять, что бы случилось при условии, если бы все другие изменения произошли, кроме изменения цены на пиво. Нужно помыслить себе параллельную реальность, в которой было так, и как-то сконструировать ее.

Это вопрос третьего уровня: что было бы, если бы. Наша предсказательная модель не способна ответить на него, не способна сконструировать параллельную реальность. На этот вопрос зачастую нельзя ответить и с помощью экспериментов. Здесь как раз нужны экономисты: в течение последнего полувека они изучают поведение людей и задают как раз такие вопросы чтоб было бы, если бы этого не произошло.

Пример такого вопроса: в 70-е годы XX века в Стране басков регионе Испании было сильное сепаратистское движение, происходило много терактов. Экономисты хотели оценить, что было бы со Страной басков как бы она развивалась экономически если бы этих терактов не было. Как экономисты это делают? Они строят параллельную реальность, в которой они строят воображаемую мирную Страну басков, и смотрят, как она развивается, какой в ней экономический рост. Результаты говорят о том, что террористическая активность в Стране басков уменьшила ее экономический рост на 10%. Тут мы можем понять, что именно такие вопросы экономиста задают уже давно, и они разработали много методов для ответа на такие вопросы. Именно этим они ценны бизнесу.

Итак, мы попробовали объяснить, чем экономисты ценны бизнесу и как они отличаются от обычных data scientist-ов. Последний вопрос нашего вебинара: Почему бизнесы будут нанимать все больше экономистов?; ответим с помощью примера онлайн-рекламы.

Компании тратят огромные деньги на рекламу онлайн и оффлайн. Если говорить в двух словах на самом деле, никто не знает, как именно работает реклама. Статус-кво среди маркетологов в том, что реклама работает. Многие экономисты имеют другое мнение, они считают, что в 90% случаев она не работает но статус-кво состоит в том, что она работает как-то (и никто не может сказать, как именно). Вопрос как именно работает реклама это как раз вопрос из 2-3 уровней лестницы причинно-следственных связей, и ответить на него хорошо с помощью предсказательных моделей невозможно.

Более конкретные примеры вопросов, которыми задаются бизнесы: Что будет с продажами, если в следующем месяце потратить на рекламу в 2 раза больше? Конечно, мы можем провести эксперимент потратить в 2 раза больше на рекламу. Но как понять потом, что новые продажи принесла именно реклама? Это могло произойти благодаря сезонным распродажам в том же месяце, или благодаря другой рекламной активности. У компании может быть много каналов рекламы, особенно у такой большой, как Zalando, и бюджеты могут меняться по многим из них. Допустим, мы хотим увеличить бюджет в одном из них и понять, что происходит с продажами но как понять, что именно это изменение привело к дополнительным продажам? Что, если продажи отложенные пользователь увидел рекламу, но покупку совершил только через месяц?
Следующий вопрос: как отвечать на такие сложные вопросы при условии, что пользователи в Европе и в других странах все меньше и меньше готовы делиться своими данными cookies и прочими? Бизнесам все сложнее отслеживать пользователей. Отслеживание пользователей за пределами вашего сайта на индивидуальном уровне невозможно в большинстве случаев; вы не можете знать, что пользователь делал на той платформе, где была ваша реклама в Facebook или Instagram. Такими вопросами задаются бизнесы, и ради таких вопросов они нанимают экономистов.

В завершение разговора про экономистов в бизнесе я хочу рассказать одну итальянскую притчу. У владельца пиццерии было два сына, и он отправил их раздавать купоны на бесплатный кофе просто чтобы привлечь больше покупателей в свою пиццерию. И он устроил соревнование между сыновьями. Сказал: я вам даю синие и красные купоны, чтобы различать, от кого пришел покупатель с купоном, и я куплю футбольный мяч тому, чьих купонов на кассе окажется больше. Один сын пошел на улицу раздавать купоны, чтобы привлечь посетителей. А другой сын остался в пиццерии и, пока отец готовил пиццу на кухне, стал раздавать купоны людям в очереди, которые уже собирались купить пиццу. Вопрос: кто же из этих сыновей победил?

На самом деле, эта притча работает и в рекламном бизнесе. Тратит ли бизнес деньги на тех людей, которые все равно купили бы тот товар, который вы продаете? Или он тратит деньги на тех людей, которых он действительно привлечет с помощью рекламы, и которые в параллельной реальности, где нет рекламы, не купили бы ваш товар? И вот, когда мы говорим об этих параллельных реальностях, когда нам нужно их помыслить и сконструировать, как раз здесь нам нужны экономисты. Поэтому бизнес их набирает.

Я расскажу, что вам делать, если вы хотите больше знать об экономике. Я могу посоветовать книги и подкасты. Замечательная книга, с которой стоит начать книга бывшего ректора РЭШ Сергея Гуриева, Мифы экономики. Оттуда я сегодня взял пример о стоимости человеческой жизни. Вы можете в этой книге прочитать о мифах, которые существуют о том, что делают экономисты и как устроена экономика, и о развенчании этих мифов. Про то, почему одни страны богатые, а другие нет, какой консенсус у экономистов и сколько работы они проделали, изучая историю стран, вы можете прочитать в книге Why Nations Fail. Про более микроуровневые задачи, когда мы смотрим не на страны, а на поведение отдельных людей, и про то, чем экономисты отличаются от normal data scientists, которые занимаются задачами предсказания или классификации, вы можете прочитать в книге Mostly Harmless Econometrics это про эконометрические методы, специальные статистические методы для изучения причинно-следственных связей. Книга The Book of Why также фокусируется на причинно-следственных связях, как раз оттуда я взял концепцию трехуровневой лестницы причинно-следованных связей; она отлично объясняет, почему бизнесам нужно все больше и больше экономистов.

Также я хотел поделиться подкастами и лекциями. На русском языке есть Экономика на слух отличный подкаст от VTimes. Также подкаст Экономика и жизнь это на YouTube-канале РЭШ; вообще, на нем можно найти много интересных лекций.

Если вы хотите почитать или послушать на английском языке, то я могу для начала порекомендовать Freakonomics это самый популярный подкаст по экономике, очень интересный. Как раз из него можно понять, насколько сумасшедшие вопросы готовы задавать экономисты и отвечать на них с помощью хороших математических и эконометрических методов. У авторов подкаста также есть свой блог на их вебсайте и несколько хороших книг, которые я тоже рекомендую.

Q: сейчас в России потолок зарплат экономистов $1000 в месяц что нужно, чтобы устроиться в Google?

На самом деле, для того, чтобы устроиться в Google экономистом, вам нужен PhD по экономике Google может себе позволить выбирать только из PhD по экономике. Хотя это не значит, что вы совсем не можете заниматься экономическими вопросами в Google: вы можете заниматься ими, будучи data scientist-ом и сотрудничая с экономистами. Это мне известно от моих коллег, которые работают в Google. Это будет не так-то просто, но, я думаю, возможно.

Если у вас будут вопросы по тому, что я рассказал, то я на самые интересные из них отвечу еще позже. Спасибо всем, кто задавал интересные вопросы и кому была интересна эта лекция.

Подробнее..

Перевод Модернизация токарного станка под работу с ЧПУ

28.02.2021 12:13:00 | Автор: admin


В нашей домашней мастерской есть токарный станок по металлу Jet GBH-1340A с устройством цифровой индикации (УЦИ). Мы давненько обсуждали возможность добавить к нему ЧПУ, потому что без компьютерного контроля некоторые виды деталей чрезвычайно сложно изготавливать с высокой точностью. Статья повествует о полученном в этом процессе опыте, включая допущенные ошибки и рекомендации по их избежанию, а также детально раскрывает весь процесс от начальной комплектации до получения готового результата.

Подготовка


Тем не менее к проекту мы подошли с некоторой долей прокрастинации. С самого начала мы выбрали контроллер частотно-регулируемого электропривода для шпинделя, шаговые моторы NEMA 34 и драйверы для осей станка на основе того, что обнаружили в нашем фрезерном станке Tormach 770. Мы также нашли в интернете интерфейсную плату с параллельным портом для управления ЧПУ. Одним из основных критериев выбора всех запчастей была их дешевизна, хотя в конечном счете пришлось переплачивать. Как говорится, скупой платит дважды.

Детали прибыли и примерно на год были отложены в сторону ввиду большого количества других активных проектов. Мы лишь изредка обращались к этому, чтобы сделать кое-какие измерения и продумать конкретное размещение шаговых двигателей. Полноценно же переключиться обратно к реализации задуманного нас заставил внезапный отказ двигателя шпинделя нашего Jet. Вот тогда уже мы достали все заготовленные детали и всерьез занялись переделкой.

Общая сводка по проекту


Затраченное время: множество выходных
Сложность: продвинутая
Стоимость: $2,500$2,800

Материалы


  • Станок металлообрабатывающий с устройством цифровой индикацией (УЦИ);
  • 3-фазный асинхронный двигатель Marathon #145THFR5329 / $500, встал на замену сгоревшего двигателя шпинделя;
  • Контроллер двигателя частотно-регулируемого электропривода Emerson Commander SK / $450;
  • Плата управления ЧПУ для LPT-порта, а именно многофункциональная плата ЧПУ C11G с сайта CNC4PC.com / $68;
  • Шаговый двигатель NEMA 34 (2 шт.) для X- и Z-осей, Model 34HS38-3008S / $110 каждый;
  • Плата драйвера шагового двигателя (2 шт.) GeckoDrive G213V / $150 каждая;
  • Компьютер с ПО Linux для ЧПУ (доступно на linuxcnc.org). Мы использовали древний Pentium 4;
  • Фильтр (электромагнитной совместимости) ЭМС Roxburgh для подавления сетевых помех;
  • Шарико-винтовая пара 40 с шариковой гайкой / $225;
  • Упорные подшипники (4 шт.);
  • Опора двигателя (2 шт.), изготовленная из нержавеющей стали и алюминия на Tormach 770 с ЧПУ;
  • Соединительная втулка (2 шт.), она же гибкая муфта вала, на Amazon от $5 до $50 в зависимости от размера;
  • Корпус блока управления, сталь, размер 241610;
  • Выключатели для питания, защитного отключения и т.д.;
  • Провода: 12ga, 14ga и 22ga;
  • Реле, выключатели и т.д. из разобранных частей станка;

Инструменты


  • Фрезерный станок ЧПУ, концевые фрезы, расточные оправки, токарные инструменты для обработки креплений двигателя.
  • Дрель, отвертки, гаечные ключи, инструменты для зачистки проводов, обжимные устройства и т.д.
  • Паяльник и олово.

Весь процесс реконструкции был поделен на три этапа:

  1. Модификация самого механизма.
  2. Сборка блока управления.
  3. Установка и настройка управляющего ПК.



Плата управления для LPT-порта/интерфейсная плата

Модификация станка. Часть 1



Наш 40 станок по металлу до апгрейда

Этот станок имеет следующие характеристики: расстояние между центрами 40 дюймов и максимально возможный диаметр заготовки 13 дюймов. По умолчанию скорость шпинделя контролируется через редуктор, расположенный за шпинделем и приводимый в действие однофазным двигателем 230В. Редуктор изменять не потребовалось; мы просто выбрали оптимальные настройки передачи, и далее при использовании ЧПУ управление скоростью уже будет осуществляться контроллером частотного преобразователя. Выход из строя оригинального однофазного двигателя, фактически, только сыграл нам на руку, так как его замена трехфазным аналогом давала большую степень контроля и позволяла удвоить максимально возможную скорость вращения, которая для умершего мотора составляла 1 750 Об/мин. Самое же удачное, что частотный преобразователь был способен преобразовать 220В из одной в три фазы. Оригинальный блок управления был снят с задней части станка, и некоторые из его контрольных реле вместе с другими деталями мигрировали в новый.


Фрезеровка первой опоры двигателя оси Z

Каретка, удерживающая режущие инструменты, предполагала два варианта управления своим движением по оси Z. (На токарном станке ось Z идет слева направо, а ось X является осью поперечной подачи). Есть основной ходовой винт для общего резания и второй ходовой винт, который вращается синхронно со шпинделем для нарезания резьбы. Оба винта приводятся в движение одним редуктором и задействуются для перемещения каретки с помощью рычагов управления на самой каретке. Мы решили убрать винт нарезания резьбы и стержень, управляющий первичным ходовым винтом. Это позволило нам приводить в движение основной ходовой винт с помощью шагового двигателя (ШД), размещенного на противоположном конце и закрепленного ремнем и шкивами. Основному винту требовалось всего чуть более 50 вращений для перемещения каретки на 1, и мы рассчитывали, что это даст некоторую степень контроля точности.


Первый вариант привода двигателя оси Z

При помощи фрезерного станка ЧПУ мы изготовили опору двигателя, которая крепится болтами к токарному станку на вертлюге, почти также как генератор в автомобиле устанавливается для натяжения ремня.


Замена вертикального суппорта: основная рукоятка оси X

Для оси X, иначе говоря, поперечной подачи, очевидным выбором стал прямой привод от шагового двигателя. Мы сняли рукоятки со станка и фрезеровали еще одну алюминиевую опору. Для снятия напряжения ходовой винт был присоединен к шаговому двигателю через соединительную муфту.


Мотор с вертикальным суппортом в сборе: новый шаговый двигатель оси X

В задней бабке токарного станка доработок мы не делали. Она останется под ручным управлением, в то время как компьютер будет выполнять всю тяжелую работу по осям X и Z.

Сборка блока управления


Оригинальный блок был слишком мал и просто не вместил бы все компоненты, необходимые для управления станком. Поэтому мы заказали корпус размером 241610, в который бы точно все поместилось. Глубина 10 была, возможно, излишней, но зато обеспечила достаточно пространства для крепления вентиляторов охлаждения и переключателей на боковой стенке. В то же время корпус оказался достаточно жестким, чтобы, будучи установленным на задней стенке станка, удерживать на себе монитор и при этом не падать.


Расположение элементов управления

Мы закрепили все компоненты на листе алюминия толщиной 1/8, который можно было вынимать из корпуса для удобства доступа. При этом он также выступал в качестве отводчика тепла. Для элементов ручного управления шпинделем мы вырезали в листе и корпусе соответствующие отверстия.


Прокладка проводов

Во избежание спутывания проводов мы добавили кабельные каналы с открытыми пазами.


Тщательно промаркированное соединение

В течение всего процесса схема обрабатывалась в Visio, где все соединения тщательно пронумеровывались, а провода для соответствия помечались с обоих концов.


Собранный блок управления (с головой Стэна внутри)


Блок управления в сборе. Первое тестирование

Весь процесс сборки блока управления занял около 60 часов.

Настройка управляющего ПК


Хоть во многих проектах ЧПУ для управления устройством и используют параллельный порт, в них зачастую не используется новейшее наиболее производительное аппаратное обеспечение. Во-первых, многие современные ПК не оборудованы параллельными портами, к тому же многие из современных процессоров оптимизированы таким образом, что хорошо работают с ПО, но малоэффективны в прямой реализации портов ввода/вывода по технологии bit-banging для чувствительного ко времени управления аппаратной частью. Это не проблема для ПК, управляющего принтером, потому что USB снижает степень нагрузки, но в нашем случае с фрезером на ЧПУ неверная конфигурация оборудования/ПО может привести к тому, что рез будет сделан в десятках тысячных долей от места, куда указывал G-code. (Например из-за пропуска шагов, прим. переводчика).

К счастью, для основных возможностей программного обеспечения ЧПУ есть списки протестированных компьютеров, так что подбирать было уже куда легче. Мы выбрали старый Dell Optiplex с процессором Pentium 4 и ОС LinuxCNC. Два таких ПК (один на запчасти) мы удачно приобрели в местном магазине подержанных компьютеров по $30 за каждый.

LinuxCNC предлагает очень широкий набор вариантов управления и отлично поддерживается сообществом компьютерных энтузиастов. Следуя инструкциям с сайта, установить LinuxCNC оказалось достаточно просто, и эта ОС отлично запустилась на нашем древнем ПК. С помощью программы StepConf мы смогли настраивать отдельные контакты параллельного порта любым нужным нам образом. Однако, как оказалось, лучше было настроить LinuxCNC до покупки каких-либо управляющих устройств, так как эта ОС предлагала предустановленные конфигурации для нескольких типов оборудования, о некоторых из которых во время начальных закупок мы попросту не знали.

Все это не заняло много времени, и наша плата для LPT-порта при нажатии клавиш уже светилась как новогодняя елка, разве что магический дым не появлялся. И вроде бы все должно было быть четко, но ничего не работало.

Скупой платит дважды


Все-таки нечестно говорить, что не работало ничего. Были намеки на практически правильное функционирование некоторых компонентов. Один из ШД реагировал на команду повернуться единственным глухим звуком. На драйвере этого двигателя даже светился светодиод зелёным вплоть до этого момента, после чего переключался на красный. Драйвер другого ШД демонстративно горел красным сразу при подаче питания и продолжал пялиться на нас, словно глаз Саурона.

Мы просмотрели всю проводку. Мы сравнили свой вариант ее прокладки с вариантом в Tormach. Здесь не было проблем. И только позже проверив с помощью позаимствованного осциллографа выход платы управления ЧПУ мы нашли первую неполадку: напряжение выходного сигнала поднималось только до половины от необходимого драйверам ШД уровня. Купленная нами за $20 плата оказалась просто мусором. Мы решили на этот раз не скупиться и нашли на другом сайте еще одну плату стоимостью уже в $99. По ее прибытии выяснилось, что маркирована она другим сайтом: CNC4PC.com. При этом она также на 6 ревизий отставала от последней предлагаемой версии. Напряжение эта плата обеспечила достаточное, и мы рассчитывали, что двигатели заработают лучше. Но они молчали

Я уже упоминал, что многое из купленного нами для собственного блока управления было выбрано по образцам из имеющегося фрезерного станка. Эти драйверы ШД были той же модели MA860H, что и в нем. Так что, рисуя в воображении счета на ремонт этого фрезера, мы начали заменять подозреваемые детали, устанавливая их в него. Шаговые двигатели были первыми, и к нашему облегчению оба заработали отлично. Следующими на проверку отправились их драйверы, и вот из них уже ни один не функционировал. Глаз Саурона продолжал насмехаться над нами. Заподозрив, что это был наш косяк, мы заказали еще пару драйверов той же модели. Оба оказались недееспособны сразу по прибытии. Один вообще отказался работать во фрезерном станке, а второй обеспечивал вращение, но только в одном направлении. Очевидно, что эти драйверы не являлись надежным решением.


Франкенштейн-драйвер двигателя: новые GeckoDrives, установленные в каркас нерабочего драйвера

Получше изучив информацию в интернете, мы вышли на модели GeckoDrive, которые полноценно оправдали наши ожидания. Эти платы отлично заработали сразу же после подключения, и обе прекрасно вписались в одно посадочное место, где ранее стоял один дешевый драйвер. При должном напряжении этим платам требовался отвод тепла, которым по умолчанию они оборудованы не были. Оставшиеся же нерабочие аналоги как раз оснащались поглотителями тепла и вентиляторами, которые оказались единственной рабочей их частью. В итоге мы просто встроили платы GeckoDrive в опустошенный каркас мертвого драйвера, решив таким образом сразу две проблемы.


Детали управления в сборе, но пока без корпуса

Новая интерфейсная плата оказалась намного крупнее изначальной, и теперь мы могли установить ее на место одного из оригинальных драйверов шаговых двигателей.

Небольшая заметка по поводу драйверов: они бывают аналоговыми и цифровыми. Вы можете найти на YouTube видео сравнения их в работе. На видео демонстрируется, и мы это подтверждаем, что цифровые экземпляры обеспечивают намного более плавную и тихую работу двигателя. Так что их повышенная стоимость себя оправдывает.

Сборка всего воедино


Все было на своих местах. Мы могли управлять ШД при помощи кнопок UI или инструкций G-code, а с помощью элементарного крепления двигателей к ходовым винтам можно было перемещать каретку вдоль обеих осей.

Мы не знали точного отношения скорости вращения ходовых винтов к боковому смещению, так что правильные установки для программы StepConf искали методом проб и ошибок. Эта программа запрашивает несколько значений: количество шагов двигателя на оборот, микрошаг драйверов, соотношение зубьев шкивов и шаг ходового винта. Если вы не уверены в этих значениях, имейте ввиду, что они перемножаются в одно значение, которое означает шаги на дюйм. Если все эти значения кроме одного (не важно какого) установить на 1, то в итоге оставшееся значение будет большим числом, которое можно подстроить с отличной точностью.

Для этого мы следовали такому алгоритму:

  • Двигаясь слева направо, переместить каретку на приблизительную известную позицию. В UI ЧПУ сбросить смещения, установив значение позиции как 0.
  • Измерить расположение каретки.
  • С помощью G-code передвинуть каретку на 1 дальше вправо, то есть к Z1.
  • Измерить новое положение каретки и посчитать разницу в дюймах.
  • Разделить значение шаги на дюйм на пройденное кареткой расстояние, получив новое значение шагов на дюйм. Например, если количество шагов на дюйм равно 20 000, и вы производите смещение на 1.015, то новое значение будет 20 000/1.015 или 19 704 шагов на дюйм.
  • Повторять процесс, пока команда выполнить смещение на 1 не будет давать конкретно смещение на 1.

Очень важно делать измерения после перемещения каретки только в одном направлении, потому что ходовой винт будет наверняка иметь некоторый люфт. Если проводить измерение после перемещения в противоположном направлении, то результат будет отклоняться вплоть до величины люфта.

Цифровой индикатор по-прежнему был прикреплен к токарному станку, что сильно упрощало процесс сравнения вводимых на ПК инструкций с фактическим перемещением каретки. Следуя разработанному нами алгоритму, мы должны были получить значение шагов на дюйм, которое бы давало согласованные результаты независимо от оси, на которой проводились измерения. Этот подход отлично работал для оси X, но при измерении оси Z результаты варьировались в диапазоне до 0.012, что зависело от места проведения измерений. В чем-то крылась серьезная ошибка.

Модификация станка. Часть 2


Ходовые винты могут быть неточными, но винт должен быть совсем плох, чтобы отклонение то возрастало, то опять уменьшалось вдоль всех 40. Проблема была в том, что помимо ходового винта в движении по оси Z были задействованы и другие шестерни, а также червячные передачи. Нам нужно было учесть неточность во всем этом связанном механизме. Люфт оси Z был таким же ужасным. В LinuxCNC есть способы компенсировать это, но для этого потребовалось бы вычислить ошибку в каждой точки вдоль всех 40 оси. Достичь желаемой точности было практически невозможно. Передаточный механизм нужно было менять.


Замеры места для расположения двигателя оси Z

Прецизионная шарико-винтовая пара (ШВП) может практически полностью устранить люфт, вопрос лишь в цене. В одной компании ШВП предлагалась аж за $3 500. В конечном итоге мы приобрели ШВП и гайку за $225 в Roton Products, расположенной в Миссури. Дополнительно потребовалась ее подгонка под купленные ранее подшипники, что в местной шлифовальной мастерской обошлось еще в $336. У данной ШВП люфт составлял уже всего 0.007, но он хотя бы не изменялся по ходу длины винта, что позволило легко это компенсировать в LinuxCNC.


Вторая опора двигателя оси Z: середина вырезана фрезой, обработана и смонтирована вместе с ШВП

Мы также решили убрать ремень со шкивом и сделать новое крепление для ШВП, чтобы можно было реализовать прямой привод от ШД.


Крепление бабки ШВП оси Z

Каждый край вала удерживается парой упорных подшипников, закрепленных один к одному для блокировки подвижности с одновременным сохранением вращения. Сам вал закреплен между этими двумя опорами подшипников под некоторым давлением.


Модифицированный токарный станок с новыми опорами, подготовленными для ШД

Любому ЧПУ требуются конечные выключатели, чтобы машина могла находить базовую позицию на каждой оси.


Монтирование конечного выключателя

К счастью, когда мы разобрали блок ручного управления, то обнаружили два переключателя без фиксации, идеально подходящих для этой цели, которые разместили в удобном положении для каждого приводного винта.

Прокладка проводов обычно осуществляется через кабельные каналы, но для оси X мы этого не стали делать, просто позволив проводам, идущим от блока управления сзади к оси X, запитываемой спереди, свободно свисать под станком.

Последние штрихи



Токарный станок с ЧПУ в действии. Тестовый запуск

Теперь у нас был полностью функционирующий токарный станок с ЧПУ. LinuxCNC работала отлично, хоть ее UI и напоминал приложение для старой Windows 98.


Скриншот LinuxCNC (Ни одна программа не загружалась, пока я не выяснил, как заставить ее игнорировать то, что она не подключена к станку)

К счастью, немного пошерстив форумы мы нашли два альтернативных UI, которые выглядели и работали на порядок лучше.

И как это обычно бывает с Linux, готовьтесь к чтению множества форумов и документации, а также редактированию текстовых файлов для получения нужной вам конфигурации.


Приспособление для заточки ножей. Рукоятки изготавливаются на токарном станке ЧПУ!


Готовое приспособление для заточки

В дальнейшем мы планируем кое-какие доработки:
  • В результате этого проекта станок лишился возможности нарезать резьбу. Тем не менее LinuxCNC поддерживает эту возможность, если удастся реализовать обратную связь от оптического датчика скорости шпинделя.
  • Будет очень кстати добавить жидкостное охлаждение СОЖ (смазочно-охлаждающей жидкостью), пусть даже для открытого станка, работающего на низких оборотах.
  • Можно ограничить люфт, заказав новые шариковые гайки, у которых каждый четвертый или пятый шарик имеет другой размер, что позволяет уменьшить погрешность между шарико-винтовой парой и гайкой.
  • ШВП необходимо защитить. Для этого нужно изготовить подходящие чехлы или хотя бы кисти для ее очистки.


Подробнее..

Анонс страх и ненависть в IT-рекрутменте

28.02.2021 20:13:53 | Автор: admin

ЗАВТРА, в 20:00 в наших соцсетях выступит Федор Волков, IT-рекрутер из Luna Park HR агенства, где работают математики и программисты.

Пока Федор учился в 57 школе, он ездил на олимпиады по математике и программированию, затем закончил мехмат МГУ. Это помогло ему нарастить огромный нетворкинг среди IT-шников и легко войти в рекрутмент.

Сейчас Федя живет в Израиле, воспитывает трех детей и помогает IT-компаниям и специалистам найти друг друга. Во время эфира он ответит на вопросы про состояние рынка, зарплаты, на что обращать внимание во время чтения вакансий, чтобы правильно понять чего ждет работодатель и многое другое.




Тезисы выступления


  • как Федя пришел в профессию и почему пока остается
  • на чем зарабатывают рекрутеры и сколько
  • как и где Федя ищет кандидатов, где они чаще всего находятся
  • как правильно читать описание вакансии, вычленить оттуда главное и понять, какого именно кандидата ищут
  • как правильно слушать IT-шников и какие вопросы задавать, чтобы определить, подходят ли они для вакансии
  • кейсы, когда вакансия закрывалась с первого раза
  • сложные кейсы, где приходило перебирать много кандидатов
  • при большом нетворкинге, можно ли подрабатывать тем, чтобы предлагать друзей на вакансии
  • где брать такие вакансии, сколько платят
  • страх выгорания у IT-шников и насколько важно вовремя предложить таким людям работу
  • как общаться с кандидатами, чтобы их заинтересовать: как первое письмо/сообщение крутому кандидату влияет на ответ


До встречи в эфире!



Подробнее..

Ink инструмент для создания текстовых квестов как из лучших воспоминаний детства

01.03.2021 16:18:41 | Автор: admin


Наверное, текстовые квесты одни из самых простых видов игр. Хоть там и требуется принимать решения, в них нет стратегических задач, а выбор заранее предопределен. Тем не менее, простые не значит плохие. Возможность влиять на сюжет книги выглядит очень привлекательно. Читатели практически всегда вступают в диалог с книгами, особенно если они хорошо написаны, переживают за героев, ругают их за нелогичные поступки, спорят с автором о сюжете. Текстовые квесты позволяют чувствовать себя полноправным участником происходящего и влиять на читаемую историю, чего так долго не хватало поклонникам обычных книг.

В сравнении с историей литературы этот жанр совсем молодой, зародился в середине прошлого века в виде экспериментов, их даже пробовали использовать для геймификации образования. Расцвет жанра пришелся на 70-е годы. Поначалу интерактивность была довольно условной, с простым ветвлением; читатель всего лишь выбирал варианты развития сюжета в духе: А что если.... Тем не менее, некоторые серии были чрезвычайно популярны. Одна из них, под названием Выбери себе приключение, издавалась почти 10 лет (с 1979 по 1988). Книги серии переводились на множество языков, включая и русский.

Следующей ступенью эволюции жанра были сольные ролевые игры, копирующие жанр Подземелья и драконы, но без гейм-мастера и других участников. К некоторым даже прилагалось игровое поле с фишками, но чаще всего можно было обойтись листом бумаги, куда заносились характеристики персонажа, или вообще одной только книгой. Тем не менее, в сложных ситуациях читатель-игрок записывал ходы, если не удавалось решить какую-то задачу с первого раза. Небольшая пасхалка из КДПВ ссылается как раз на одну из таких книг.


Игра запущенная на DPD-10

Компьютер дал подобным играм второе рождение. Первый текстовый квест Colossal Cave Adventure был написан на фортране в 1975 году и работал на мейнфрейме PDP-10. Уже тогда рабочие компьютеры использовались как средство развлечения за счет начальства. Создатель игры, Уильям Краудер, был не только программистом, но и спелеологом, потому сюжет был о поиске сокровищ в пещере, у которой был реальный прототип Мамонтова пещера в американском штате Кентукки. ОНа знаменита тем, что является самой длинной в мире (общая длина исследованных проходов больше 500 километров); есть где спрятать сокровища!

Уйльям очень ответственно подошел к разработке: локации соответствуют помещениям в настоящей пещере и описаны очень точно, а в игре Уильям использует реальный спелеологический жаргон. Домик с ручьем снаружи, другие детали, типа решеток, перегораживающих отдельные ходы пещеры, вырубленные ступени тоже существовали в реальности на тот момент, но некоторые были переделаны или снесены.


Одно из реальных мест в пещере, описываемое в игре.

Программа выступала в роли гейм-мастера, описывая окружение локации, куда попал игрок, с юмором комментируя его действия и храня список предметов, которые находятся в инвентаре. Текст, который писала программа, выводился большими буквами, действия игрока маленькими. Игра относится к тому типу, в котором для управления требуется вводить короткие команды из двух-трех слов.

В СТОИТЕ В КОНЦЕ ДОРОГИ ПЕРЕД НЕБОЛЬШИМ КИРПИЧНМ ЗДАНИЕМ.

ВОКРУГ ВАС ЛЕС. НЕБОЛЬШОЙ РУЧЕЙ ВХОДИТ ИЗ ЗДАНИЯ И СПУСКАЕТСЯ В ОВРАГ.

иди на юг

В НАХОДИТЕСЬ В ДОЛИНЕ В ЛЕСНОЙ ДОЛИНЕ, РЯДОМ С РУЧЬЕМ, КОТОРЙ СТРУИТСЯ ПО КАМЕННОМУ ДНУ.

Формального сюжета и конкретной цели не существует. У игрока есть три жизни, которых ему должно хватить, чтобы набрать 350 очков, необходимых для выигрыша. Очки выдавались за исследования пещеры и найденные сокровища. Первоначально в игре было 66 локаций, количество которых увеличивалось с каждой следующей версией. Позже развитием игры занялся Дон Вудс, который тогда был аспирантом в Стэнфордском университете. Под его началом в следующей версии количество локаций расширилось до 140. Однако Дон никогда не был в Мамонтовой пещере, и добавленные им локации уже не совпадают с реальностью.

В 1977 году James Gillogly впервые портировал игру на другую систему, а именно на Unix. Что любопытно, этот порт до сих пор входит в состав некоторых дистрибутивов, а если его нет, то можно установить в составе репозитория bsdgames (или отдельно) и играть даже на VPS через SSH.

Установка и запуск игры на Ubuntu
$ sudo apt install colossal-cave-adventure                                           $ adventure                                                           WELCOME TO ADVENTURE!! WOULD YOU LIKE INSTRUCTIONS?                                                                                                                  > yes                                                                    SOMEWHERE NEARBY IS COLOSSAL CAVE, WHERE OTHERS HAVE FOUND FORTUNES IN                                   TREASURE AND GOLD, THOUGH IT IS RUMORED THAT SOME WHO ENTER ARE NEVER                                    SEEN AGAIN. MAGIC IS SAID TO WORK IN THE CAVE. I WILL BE YOUR EYES                                    AND HANDS. DIRECT ME WITH COMMANDS OF 1 OR 2 WORDS. I SHOULD WARN                                     YOU THAT I LOOK AT ONLY THE FIRST FIVE LETTERS OF EACH WORD, SO YOU'LL                                   HAVE TO ENTER NORTHEAST AS NE TO DISTINGUISH IT FROM NORTH.                                      (SHOULD YOU GET STUCK, TYPE HELP FOR SOME GENERAL HINTS. FOR INFOR-                                   MATION ON HOW TO END YOUR ADVENTURE, ETC., TYPE INFO.)                                                          - -                                                     THIS PROGRAM WAS ORIGINALLY DEVELOPED BY WILLIE CROWTHER. MOST OF THE                                   FEATURES OF THE CURRENT PROGRAM WERE ADDED BY DON WOODS (DON @ SU-AI).                                   CONTACT DON IF YOU HAVE ANY QUESTIONS, COMMENTS, ETC.                                                                                                                  YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.                                    AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND                                    DOWN A GULLY.                                                                                                                                      >

Так как Дон активно распространял исходный код своей версии, то это способствовало росту ее популярности и тому, что она портировалась на каждую новую платформу: Apple, Commodore и, конечно же, MS-DOS.

Версия для MS-DOS была уже с простейшей графикой, содержала 130 локаций, 15 видов сокровищ, 40 предметов для инвентаря и 12 задач, которые требовалось решить по мере прохождения.


Игра на MS-DOS

В 1985 году Дэйв Платт выпустил свою версию игры, где надо было набрать уже 550 очков, но которая кардинально отличалась подходом к программированию таких игр. Он создал универсальный язык написания сценариев A-code, который обрабатывался движком написанным на FORTRAN 77. Это позволило очень легко делать модификации игры и создавать другие текстовые приключения. Практически все современные игры создаются подобным образом, на специальном языке разметки, который интерпретируется движком, как универсальным, в который можно загружать самые разные игры, так и проприетарным, выдающим исполняемый файл, который можно продавать в онлайн-магазинах.

Приключение Colossal Cave Adventure было родоначальником жанра и надолго сформировало каноны подобных квестов, а так же очень сильно повлияло развитие ролевых игр, в том числе и многопользовательских. Жанр MUD создавался по образу и подобию CCA. Даже Дональд Кнут не обошел вниманием эту игру и написал небольшую книгу, посвященную анализу кода игры в обучающих целях.

CCA является настоящим долгожителем. Дон Вудс продолжал выпускать обновления вплоть до середины 90-х, а в 2017 году Эрик Реймонд взял версию игры Дона от 1995 года, отладил ее, чтобы она запускалась на современных компьютерах, и выложил код на своей странице. Существует порт игры на Андроид и переводы ее на русский язык. Поиграть в один из приведенных вариантов можно на сайте Русский Информ, платформе для создания подобных текстовых игр. Можно играть как онлайн, так и скачав файл для движка Windows Frotz.


CCA на Windows Frotz

Наверняка, поиграв в AAC, кто-то вдохновится на создание собственного текстового квеста, тем более, что они все еще очень популярны. Современные возможности компьютеров позволяют дополнять их яркой графикой и анимацией, музыкой и звуками окружения, создавая увлекательные и современные игры, но не выходя за границы жанра. Для подобного творчества существует множество инструментов. Я хочу познакомиться вас с одним из них. Его отличает то, что это не просто программа написанная для развлечения, а реальный инструмент, используемый коллективом разработчиков для создания красивых и популярных игр, высоко оцененных любителями жанра и хорошо продающихся на всех современных платформах.

В 2011 году пара разработчиков из Кембриджа занялась производством интерактивных текстовых квестов и придумала средство для упрощения своей работы Inklewriter. Год спустя они представили его в виде сайта, который позиционировался как простое средство для обучения программированию и создания интерактивной литературы. Его даже использовали в школах и удостоили награды Best Website for Teaching and Learning от Американской ассоциации школьных библиотек. Спустя несколько лет разработчики были вынуждены закрыть его по причине нехватки времени на его поддержку, но открыли код своего инструмента для работы (позже они его перезапустили). Ink получил возможность интеграции с Unity, и с его помощью стало возможно с легкостью создавать интерактивные истории, сочетающие в себе не только текст с рисунками, но и музыку с анимацией. Он был взят на вооружение и другими крупными инди-студиями разработки игр, а сама Inklestudios выпустила несколько успешных игр для разных платформ: ссылка. Игры очень милые, другого слова не подобрать. Им удалось заполучить в команду талантливого художника Anastasia Wyatt, что замечательно рисует.


Хоть создатели не считают Ink языком программирования, а только средством для разметки, интерактивные скрипты умеют не только обрабатывать ветвления, но и работать с переменными, использовать логические и математические операции и даже простейшие функции. Повествование может включать несколько потоков, чтобы автор мог более полно охватить возможные действия игрока и последствия его выбора.

Проект Inkle состоит из двух частей: руководство по языку разметки ink; IDE для работы с ним Inky. Начать писать интерактивную историю очень просто. В Inky два окна: слева текст сценария, справа его интерпретация


Начнем новый сценарий: File New Project. Вставим в редактор следующий пример и сохраним в отдельную директорию: File Save Project.

Текст сценария
Лондон, 1872Резиденция месье Филеаса Фога-> london=== london ===Месье Филеас Фогг рано вернулся домой из Реформаторского клуба, да к тому же в новомодном паровом экипаже!Паспарту,  сказал он.  Мы едем вокруг света!+ Вокруг света, месье?Я был крайне удивлен.-> astonished+ [Кивнуть] -> nod=== astonished ===Вы шутите!  ответил я с достоинством.  Вы смеетесь надо мной, месье.Я совершенно серьезен.+ Как скажете, месье.-> ending=== nod ===Я кивнул, не веря ни одному его слову.-> ending=== endingМы совершим кругосветное плавание за восемьдесят дней.  Он был совершенно спокоен, когда предложил этот дикий план.  Через час, в 8.25, мы вылетаем в Париж.-> END


На приведенном фрагменте очень простая структура:

  • тройными знаками = обозначены Узлы (в терминологии Ink), метки для перехода;
  • переход по ним осуществляется с помощью оператора ->.->;
  • пункты выбора обозначаются оператором +;
  • квадратные скобки сообщают интерпретатору, что после выбора название пункта не надо отображать в диалоге;
  • END оператор окончания текста.

Интерпретация всегда идет сверху вниз. Если повествование разделено на узлы, в начале следует сделать переход на основной поток: -> london.

История готова, но выглядит довольно скучно. Добавим в нее изображение. Для этого используется тег # IMAGE.

# IMAGE: days-poster-promo.jpg

Наглядно

Картинка должна лежать там же, где файлы экспортированные для интернета. После внесения изменений экспортировать достаточно один файл: File Export story.js only, остальные содержат шаблона, в который помещается история.

Написав историю, можно экспортировать ее в интернет: File Export for web. В директории проекта появятся несколько файлов: HTML-страница; стилевое оформление в CSS; файл движка ink.js; наш сценарий 80d.js (не редактируйте его напрямую); main.js, где описывается поведение сценария. Если вы знаете CSS, то вам не составит труда отредактировать внешнее оформление истории.

Закончив оформление, историю можно выложить в интернет. Авторы Ink рекомендуют воспользоваться порталом itch.io. Это бесплатный портал с простой регистрацией. При создании проекта для Ink выберите Kind of project HTML, загрузите архив с файлами проекта и отметьте опцию This file will be played in the browser. Можно посмотреть, что получилось: ruvds.itch.io/inky-test.

Если вам в свое время тоже хотелось дополнить текстовые квесты Рейнджеров или написать свой текстовый квест, то не стоит сдерживать свою фантазию дерзайте вместе с Inky!

Подробнее..

11 мифов о хостинге. Открытка ко дню хостинг-провайдера

01.03.2021 18:19:29 | Автор: admin
Даже из нас, завсегдатаев Хабра, немногие каким-то особым образом задумываются о том, что и почта, и телефония, и рабочая CRM-ка, и сам Хабр, и весь интернет находятся на удалённых серверах по всему миру в дата-центрах высочайшего класса (ну или просто в дата-центрах, зависит от ресурса). А за каждым дата-центром стоят люди: люди, которые не спят ночами; люди, которые в самый разгар карантина и ковида выходили на работу; люди, которым мы доверяем самое ценное в виртуальном мире данные. День хостинг-провайдера молодой праздник, который тем не менее не случайно отделён от дня системного администратора и от дня бэкапа (есть что-то символичное в том, что день хостинга в первый день марта, а день бэкапа в последний). Ведь в жизни сотрудников хостинга всё меньше системного администрирования и всё больше управления безопасностью, мониторинга, разработки, скриптинга и проч. Это настоящие супермены на страже надёжного, стабильного и безопасного хранения данных.

Сегодня в не самом серьёзном посте мы поговорим о главном о мифах, которые часто портят отношения хостера и клиента. Джейми хочет большой бум.



Виртуальный хостинг небезопасен!


Безопасность виртуального хостинга (VPS и VDS) один из самых обсуждаемых и проблемных вопросов. Каких легенд здесь только нет: сотрудники хостера читают и крадут данные компаний, хакеры держат устойчивый канал по мониторингу хостинга, серверные залы дата-центров могут посещать все желающие, особенно люди с автоматами. Эти байки редко имеют под собой какую-либо адекватную основу.

Любой серьёзный хостинг-провайдер поставляет высокозащищённые VPS корпоративного уровня: за серверами следит обученный штат квалифицированных сотрудников, любой дата-центр автоматизирован и оснащён системами мониторинга и резервного питания, все вторжения обнаруживаются и пресекаются. Что касается физической безопасности, то ЦОДы защищены так же, как и спецобъекты: охрана, системы видеонаблюдения и СКУД, пожаробезопасные и вандалоустойчивые здания. Чтобы пробраться в современные дата-центры и причинить им вред, нужно быть как минимум хорошо вооружённой и довольно большой группировкой прошаренных айтишников и инженеров. А им явно не до этого.

Бесплатный хостинг рулит зачем платить?


Бесплатный домен, бесплатный хостинг казалось, что может быть лучше? Вырученные деньги можно вложить в раскрутку и привлечение пользователей. Однако привлечённые пользователи могут загрустить, потому что просто не попадут на ваш сайт. Дело в том, что бесплатный хостинг скрывает за собой множество тайн, а именно ограничений: по скорости соединения, по количеству одновременных посетителей, по количеству пользователей одного публичного сервера (а это ещё и и зависимости условно говоря, если с вами на одном сервере окажется хакер или торговец веществами и его забанят органы, то и ваш сайт окажется заблокированным).

Кроме того, как правило, у бесплатных хостингов низкие гарантии безопасности, низкий SLA и либо платная, либо крайне ограниченная и неспешная техническая поддержка. Проще говоря, бесплатный хостинг это скорее куча проблем, чем способ успешно сэкономить. Более того, бесплатный хостинг может оказаться маркетинговым решением, которое призвано завлечь вас на дорогой тариф или просто в один прекрасный день ввести плату за любые услуги или техническую поддержку.

И да, содержать дата-центр с хорошим оборудованием, всеми российскими и международными лицензиями и сертификатами очень дорого, часть этих средств ложится в стоимость тарифа (на то она и аренда VPS). Если в договоре с провайдером нет имени Робин Гуд, слов благотворительность и всё ради вас, дорогие, то задумайтесь почему так дёшево или бесплатно? На чём они сэкономили и как со мной будут разделены эти риски?

Аптайм 99,9% ложь


Адепты низкого аптайма утверждают, что 99% недостижимый маркетинговый уровень и любой хостер обеспечивает частые простои лучше, чем свои услуги. Ну, может быть, для бесплатных и мусорных хостингов это и справедливое утверждение у них просто нет инженерного и человеческого ресурса для обеспечения стабильной работы. Однако крупные провайдеры обещание держут: аптайм составляет даже более 99%, а любые проблемы решаются буквально молниеносно во многом за счёт автоматического переключения на резервные системы, быстрого обнаружения инцидента и реагирования на него.

Поэтому такие значения аптайма не миф, а реальное значение.


Кто сказал, что у гиков нет ночной жизни? (Они бдят аптайм!)

Отзывы и рейтинги хостингов фуфло


В появлении этого мифа нет ничего удивительного: многие бизнес-сервисы придумывают рейтинги под себя и для сбора денег за участие или удаление отзывов, проплачивают отзывы или генерируют их с заброшенных аккаунтов в социальных сетях. Однако с хостингами эта история не пройдёт: у них настолько много клиентов, что просто не получится уследить за всеми, а поддельные отзывы быстро утонут в массе реальных. Поэтому рейтингам хостингов и отзывам на них на крупных трастовых площадках доверять можно это мнение реальных пользователей (правда, с погрешностью на тех, кто не справился с работой и зол сам на себя). Кстати, отсутствие негативных отзывов, в свою очередь, вас должно насторожить: либо вы попали на ангажированный рейтинг, либо провайдер не особо популярен, поэтому ему достаточно отзывов, написанных его же сотрудниками. Не бывает хостинга абсолютно без проблем а значит, и отзывов без негатива быть не должно.

А вот обзоры как раз могут быть фальшивыми или купленными, поэтому выбирайте не монообзоры, а обзоры, в которых сравниваются разные решения. Важный момент: если в обзорах есть бенчмарки, совсем не обязательно, что вы получите за свои деньги такой же результат. Тесты как правило проводятся в лабораторных условиях: на чистых машинах или под чистой нагрузкой с коротким пингом. Поэтому реальный опыт использования может оказаться как чуть лучше, так и чуть хуже описанных в материалах провайдера. Однако у хороших хостеров это незначительные отличия, которые могут оценить только профессиональные админы и девопсы.

Хостинг у регистратора домена это удобно!


Это самый-самый распространённый миф. Действительно, что может быть проще: один поставщик, единый счёт, одни отношения. Кажется, это удобный вариант как для физических, так и для юридических лиц. Однако в большинстве случаев хостинг у регистратора домена это лишь временное решение, которое однозначно не должно вас устраивать, поскольку ни один регистратор не предлагает такого набора опций и мощностей, как это делает хостинг-провайдер.

Поэтому, если у вас достаточно нагруженный сайт или облачный сервис, от услуг регистратора домена по хранению данных лучше отказаться. Точно так же стоит отказаться, если вы собираетесь свой небольшой проект развивать и масштабировать вам понадобятся гибкие решения с различными свойствами и наборами услуг. Пакетов регистратора может просто не хватить.


Скорость сайта/приложения на 100% зависит от скорости хостинга


Это миф, но частично. Скорость сайта и приложения зависит прежде всего от их архитектуры, дизайна, особенностей программных находок и методов. Например, каждая страница сайта одного из кафе весила 29 МБ, поскольку в основном содержала хайрезную фотографию странички меню. Конечно, грузился он очень медленно. Немаловажную роль в скорости загрузки играет и скорость соединения у конечного пользователя понятно, что самый оптимизированный сайт или веб-приложение на скорости 3G будет загружаться с трудом. Это внешний фактор, на который нельзя повлиять, но который нужно учитывать и предусматривать как оптимизацию решения в целом, так и адаптивные версии.

Но роль хостинга в скорости вашего сайта или приложения слишком высока, чтобы выбирать слабое решение. Поэтому если вы рассчитываете на большой поток посетителей, выбирайте защищённый и мощный ресурс, чтобы загрузка была максимально быстрой. Современные пользователи отвыкли ждать загрузку сайта и даже 2-3 секунды задержки могут привести к тому, что вы потеряете своих посетителей навсегда. Сайт и веб-приложение должны работать незаметно.

Дешёвый хостинг вас подведёт, а дорогой нет


Увы, заоблачная цена не гарант качества хостинга. Провайдеры с исключительно высокими ценами рассчитывают на то, что клиенты выберут их, не заморачиваясь вопросами сравнения нескольких провайдеров. Наоборот, крупные хостинговые компании предлагают широкую линейку тарифных планов: во-первых, на любые цели (студенту, фрилансеру, крупной корпорации нужны разные решения), на любой бюджет, а главное, с целью дать возможность протестировать свои услуги и убедиться в их качестве, чтобы затем перейти на более дорогой и продвинутый тариф.


Живые люди по-прежнему решают больше, чем роботы. Нет пока доверия искусственному интеллекту

У любого хостера есть свои дата-центры


К сожалению, нет. Есть компании, которые решают войти на рынок веб-хостинга или предоставляют такие услуги как побочный продукт (например, облачная CRM и веб-хостинг для различных бизнес-целей). По сути, они выкупают хостинг у крупного провайдера и перепродают мощности с наценкой либо арендуют сервера в чужом дата-центре. Обращаться к таким компаниям рисковая история, поскольку слишком велика цепочка взаимодействий и возможность невыполнения требований внутри этой цепочки (условно говоря, если субхостер не заплатит владельцу серверов, санкции лягут на плечи конечных клиентов и договориться напрямую будет практически невозможно). Кстати, 2018-2019 годы были богаты на такие события в российском сегменте хранения данных.

Все провайдеры предлагают одно и то же


Это только на первый взгляд. Каждый из хостинг-провайдеров, от самых мелких до самых топовых, стремится конкурировать как в ценовом поле, так и за счёт неценовых факторов. Отличия могут быть в расположении и надёжности дата-центров, в наборе инструментов администрирования, в возможностях администрирования, в качестве и уровне технической поддержки, в наборах готовых образов и предустановленных программ, в уровне самого серверного оборудования, дополнительных опциях, страховке и т.д.

Поэтому перед выбором своего хостинга важно не только определиться с набором задач, но и сравнить 2-3 предложения от разных компаний, вникнув в детали.


Что ты творишь?!

Ну ты же говорил, что хочешь сделать 360-градусный обзор нашего дата-центра?

(ЦОДы взрослым не игрушка!)

Я не справлюсь с серверами!


Сидите на Хабре, ковыряете Kubernetes, развиваете DevOps? А хотите вернуть свой 2007? Попробуйте что-то внедрить в средне оптовой или торговой компании: никакой автоматизации, контроль трафика, шредер, принтер, зажевавший скрепку и 1С. А ещё сисадмин и своя серверная! Нереальная роскошь и предмет особой гордости. На борту, между, прочим, Windows Server 2003, а то и 2008! Если убраться в серверной, можно найти пейджер. Ну ладно, про пейджер это мы преувеличили. Но факт в том, что компании тащат легаси софт и легаси железо, боясь перейти в облака: а вдруг дорого, опасно, а вдруг не справимся, а вдруг миграция порушит всё, что нажито непосильным трудом?

Это напрасные страхи и совершенно необоснованное мучение со старыми мощностями. Во-первых, сотрудники хостинг-провайдера помогут с миграцией любой сложности, во-вторых, админские инструменты хостера настолько совершенны, что проблем с ними не возникнет даже на больших объёмах данных и решаемых задач. Удобные панели, готовые образы, предустановленный софт это минимум, который вам предложит хороший провайдер.


Если есть VPS/VDS, сисадмин в компании не нужен


Тоже распространённый миф, но отчасти справедливый. Если у вас небольшая компания и есть менеджер или руководитель с мозгами и примерно прямыми руками, он справится с VPS, ведь он не одинок есть техническая поддержка и сотрудники провайдера.

А вот если у вас мощности побольше, есть разработка или сложное, чувствительное к простоям, корпоративное ПО, вся офисная телефония и виртуальная АТС в облаке, или вы поставляете облачные приложения своим клиентам, системный администратор строго обязателен. Более того, это должен быть не эникейщик, а профессионал, способный решать проблемы самостоятельно и совместно с сотрудниками хостинг-провайдера, способный распознать и классифицировать инцидент собрать данные, работать с мониторингом, контейнерами, панелями управления и т.д. Конечно, многое зависит от профиля деятельности компании, но в целом, если бизнес работает с данными (будь то клиентская база или склад), сисадмина лучше держать под рукой. Это важная часть информационной безопасности компании.

И да, наличие системного администратора в компании не отменяет необходимости технической поддержки со стороны провайдера. Это взаимодополняемые, но не взаимозаменяемые функции.

Ну а своим коллегам в день хостинг-провайдера желаем надёжного пинга, адекватных клиентов, шустрых серверов, аптайма 100% и никаких гвоздей, ну и, продолжая традиции связистов, за связь без брака!
Подробнее..

Перевод Заметки о Unix С-функция main() одно из мест, где видны различия между API пользовательского пространства и ядра Unix

03.03.2021 12:06:10 | Автор: admin
В современных Unix-дистрибутивах часто проводят формальную границу между API, предоставляемыми пользовательскому пространству ядром, и Unix API, которые предоставляет программам стандартная библиотека, под которой подразумевается стандартная библиотека C. Кое-кого, включая меня, это не вполне устраивает (я уже писал на эту тему). Но, независимо от того, что я об этом думаю, в Unix уже давно существует одно место, в котором видна разница между обычным API, которым пользуются все, и API, который реализован в ядре. Я говорю о традиционной точке входа в программы, написанных на языке C, о функции main(), с которой начинается выполнение таких программ.



Все знакомы с простой формой функции main(), в которой используются аргументы argc и argv. Такая функция вызывается с передачей ей количества аргументов и массива строк. При несколько более продвинутом способе работы с этой функцией применяется ещё и третий аргумент envp. Он представляет собой массив переменных окружения. Этот формат существует в Linux очень давно. Версия main() с двумя аргументами существует, как минимум, со времён exec(2) Research Unix V4. А форма этой функции с третьим аргументом, похоже, появилась в exec(2) V7.

Но это, на самом деле, не реальная точка входа в программу, которую ядро Unix V7 использует при запуске программы. Реальная точка входа имеет API, отличный от main(). Обычно C-программы в V7 начинают работу с метки, имеющей символическое имя start. Самая простая версия ассемблерного кода, в котором это используется, представлена в файле crt0.s, и тут, очевидно, выполняется некий объём подготовительной работы. Есть и другие версии подобного кода, их можно найти здесь. Тут выполняется больше вспомогательных операций, например подготовка к профилированию кода.

(В Research Unix V6 тоже был файл crt0.s, но несколько иной. Полагаю, тут, например, нет циклов. Если бы я понимал язык ассемблера PDP-11, то я лучше бы разобрался с тем, что тут, на самом деле, происходит.)

В V7 между API пользовательского пространства для main() и API ядра имеется лишь небольшая разница. В актуальных дистрибутивах Unix там часто происходит очень много всего, особенно тогда, когда пользуются динамическими загрузчиками и чем-то вроде вспомогательного вектора, который имеется в некоторых дистрибутивах. Я подозреваю, что самую простую современную версию этого механизма можно найти в musl libc для Linux, где crt1.c и функции libc для подготовки к работе main() сравнительно просты.

(Некоторый код тут присутствует из-за того, что среда выполнения C нуждается в предварительной настройке (и да, в современном C есть среда выполнения), но определённый объём этого кода предназначен для согласования того, как ядро вызывает программы, с тем, как хочет быть вызвана функция main(). Например, обратите внимание на то, что функция musl libc для запуска main() не вызывается с передачей ей argc в виде явно заданного аргумента. Она извлекает argc из памяти.)

Примечание: V7 и адрес данных 0


В конце каждой версии файла crt0.s V7 есть код, который поначалу меня озадачил:

.data.=.+2  / loc 0 for I/D; null ptr points here.

Оказалось, что он резервирует два байта в начале раздела данных. Unix V7 работает на компьютерах PDP-11, которые поддерживают разделение адресного пространства инструкций и данных. В результате раздел данных начинается с адреса (данных) 0. Резервирование двух байтов в начале адресного пространства позволяет обеспечить то, что ни переменную, ни что-то другое в разделе данных нельзя расположить по адресу 0. В результате NULL в C всегда отличается от действительных указателей.

Приходилось ли вам сталкиваться с различиями API пользовательского пространства и ядра Unix?

Подробнее..

Ящик пива за лучшую сисадминскую байку и наш личный топ историй

03.03.2021 16:23:30 | Автор: admin
Мы в очень любим три вещи: сисадминов, байки и пиво.

В этот раз мы решили объединить эти любимые вещи и сделать конкурс лучших сисадминских баек: про работу, клиентов и забавные случаи из практики.


Ммммм, сисадмин-техпод-байка-пиво

Каждому, кто расскажет забавную историю в комментариях, мы подарим по баночке нашего фирменного , а победителю, чей рассказ наберет больше всего плюсов вышлем целый ящик пива.

Для вдохновения и правильного настроя, делимся нашими любимыми сисадминскими байками: тут почти нет новых историй, зато много ностальгии, доброго юмора и даже пара нерешенных до сих пор загадок. Поехали?



Раньше я работал в IT-отделе компании Samsung. Одному из сотрудников нужно было сбросить пароль, я сменил пароль на Samsung1 и сказал ему об этом. Мне перезвонили через две минуты и сказали, что пароль не подходит. Я снова сбросил его, но он снова не сработал. Я подумал, что проблемы со стороны пользователя и решил зайти к нему.
Каково было мое удивление, когда я увидел, что он неправильно набирает пароль! Он печатал Semsung1.
Подсказываю! Это компания, в которой вы работаете, и ее название написано на мониторах, перед которыми вы сидите

Питер Дж.




Это было в начале 2007 года. В нашем колледже строили Центр обработки данных в переоборудованном классе, практически не обращая внимания на климат-контроль, а тогда там стоял обычный сплит-кондиционер. Наш колледж находился в юго-западной части пустыни Мохаве, в Южной Калифорнии. В нем экономили деньги каждые выходные отключая все кондиционеры по всему кампусу, в том числе и в центре обработки данных, так что наши серверы пыхтели при 50-60 градусной жаре до утра понедельника. В марте 2007 года мы обратились к поставщику резервных копий, так как у нас был ленточный накопитель Quantum LTO1 (только с одним отделением для кассеты), и он глючил из-за жары в нашем . Нам нужен был надежный накопитель, который бы выживал в наших условиях. Но существующее решение не могло делать копии открытых файлов, потому нам нужна была неделя на то, чтобы собрать полный набор данных (из-за медленного накопителя). Мы попросили денег на резервный узел SAN для подсраховки в случае падения, но нам отказали.

Вместо этого нам выделили деньги на работу сторонней компании, выполняющей резервное копирование в сжатые сроки. Выезд их специалистов запланировали 17 июля 2007 года в 8:45, чтобы они делали нам полный бекап. В точности по Закону Мерфи наша SAN вышла из строя ночью, прямо перед запланированным приездом специалистов по бекапу, а один из на 900 ГБ был потерян навсегда.
Да здравствует планирование!

Джастин Дж.



У нас в компании было совещание руководителей отделов для обсуждения работы с компьютерной системой службы 911. Инструкции разослали утром в пятницу, чтобы начать тренинг по работе в ней уже в понедельник.
Два пользователя, не особо вникая текст письма, активировали систему по инструкции сразу, как только получили письмо, наведя шухер среди офицеров полиции работающих в 911.

Зак Д.



Как и большинство системных администраторов я начал с работы в службе поддержки.
Однажды мне потребовалось более 20 минут, чтобы объяснить новой работнице, как нажать CTRL-ALT-DEL для входа в компьютер. Она просто не могла понять концепцию одновременного нажатия 3 клавиш сразу

Конрад Дж.



Как-то рабочий, обслуживающий коммуникации в фальш-потолке, где были проложены наши сетевые кабели, случайно их перерезал. Когда наши инженеры прибыли на место для устранения обрыва, рабочий сказал, что все в порядке, и он сам все исправил.

Он соединил обрывки витых пар колпачками для скрутки проводов.

Уоллес Ф.



Однажды я чуть не сошел с ума, пытаясь понять, где сбой в питании, проведенном через фальш-пол. Вдруг мы услышали голос из соседней комнаты: О-ля-ля! Ты вылила всю мою бутылку воды на розетку!.

Мы побежали туда и увидели розетку, залитую лужей воды

Хорхе Б.



Лет 10-25 назад я работал в поддержке у провайдера, в какой-то момент мне позвонила женщина, которая сразу призналась, что не умеет обращаться с компьютером, но ей очень надо запустить одну программу. Она жила всего в паре минут от меня, и я решил просто зайти к ней домой.
Придя на место, я сказал, что сначала ей надо открыть меню Пуск. Она спросила меня: Что такое Меню Пуск? Постепенно я ей все объяснил и нашел приложение, которое ей было нужно. Когда я собрался уходить, она сказала, что знает еще одного человека, которому я могу помочь. Оказалось, что у нее есть маленькая дочь, и та слышала, что можно превратить курсор мыши в динозавра. Это было просто, я всего лишь поменял тему курсора Windows XP, но девочка была счастлива.

Вернувшись в офис я заполнил тикет: Помог пользователю найти приложение Х и превратил курсор мыши в динозавра.

Энди С.



Помню, у меня на работе жила саламандра в аквариуме, которая все время умудрялась вылезать из него, хотя крышка была закрыта. Однажды, она вылезла, когда никого не было, и пропала.
Через некоторое время мой компьютер отказался запускаться из-за проблем с блоком питания. Когда я открыл корпус, то увидел палочку, застрявшую в вентиляторе.
Только это была не палочка!..

Роб Х.

У нас был клиент, который прислал нам фотографию своего треснувшего экрана
сделанную с помощью Print Screen.

Лим Р.



Когда я работал в техподдержке, я, было, уделено помогал одному пожилому человеку. Когда мы со всем разобрались, я попросил его закрыть все окна, чтобы мы могли повторить все сначала. Он сказал Хорошо, скоро вернусь. Через десять минут он снова подошел к телефону и сказал: Ну, я закрыл все окна, и что теперь?
Райан Г.



Однажды я отошел от рабочего компьютера, оставив его включенным и не заблокировав заставкой с паролем. Никогда этого не требовалось, потому что коллектив был меньше десяти человек, все работали вместе несколько лет и довольно хорошо друг друга знали. Вернувшись, я увидел, что в моей аське мигает почти весь контакт лист, все мне что-то пишут, включая тех, с кем мы общались очень редко и даже не каждый месяц.

Оказалось, почему-то именно в тот день одному коллеге ударило в голову неизвестное вещество, и он решил пошутить, сев за мой кмоп и написав в мою аську: Я тряс башкой и мой хаер застрял в клавиатуре, а потом одной кнопкой разослав это по всем моим контактам (спасибо Аське, тогда это можно было сделать буквально в один клик).

Я пережил несколько неприятных минут, объясняя, что это глупая шутка коллеги. Но с ним больше не здоровался А компьютер блокировал.

Константин В.



Был случай, когда к нам в офис устроился сотрудник, который, как бы сказать поделикатнее, пренебрегал личной гигиеной. Всех достало его амбрэ, но сказать прямо стеснялись. В итоге, решили проблему довольно замороченным способом, но зато по-админски.

На компьютере Макинтош можно сбросить пароль root-пользователя с помощью специальной опции на установочном диске. Мы загрузили его Мак с этого диска, сбросили пароль root, завели еще одного пользователя и задали ему известный нам пароль. Потом зашли под root, открыли файл с хешем пароля того сотрудника, скопировали его в отдельный файл, а на его место вставили хеш пароля нового пользователя. Это позволило нам зайти в учетную запись пахучего сотрудника, использовав пароль временного пользователя. Мы поменяли на десктопе фон, поставив картинку с младенцем и большой надписью: Даже малые дети знают, что надо принимать душ каждое утро и пользоваться дезодорантом!.

После этого снова зашли под root, скопировали обратно хеш его пароля из сохраненного файла и вставили его обратно, а временного пользователя удалили.

На следующее утро мы с предвкушением ждали его реакции и были вознаграждены громким возгласом изумления, раздавшимся тогда, когда он загрузил свой компьютер. Наши старания были не напрасны, парень стал принимать душ и пользоваться антиперспирантом!

Константин В.



Несколько лет назад, работая в Лаборатории искусственного интеллекта МТИ (на самом деле очень много, потому что описывается компьютер из 60-х годов), я рылся в шкафах, где находился мейнфрейм PDP-10, и заметил маленький переключатель, приделанный к раме одного шкафа. Очевидно, это был прикол, который добавил один из местных хакеров.

На самом деле, есть правило: Не трогать переключатель, если вы не знаете, что он делает, потому что это может привести к сбою компьютера. Но этот был маркирован совершенно дурацким образом, у него было два положения, и на металлическом корпусе карандашом были нацарапаны слова магия и больше магии. Тогда тумблер был в более волшебном положении.

Я позвал другого сотрудника, чтобы он посмотрел на это чудо. Но он тоже никогда раньше не замечал его. При более внимательном изучении выяснилось, что к выключателю подведен только один провод, который скрывался в лабиринте внутри компьютера. Логично, что выключатель не может ничего делать, если к нему не подключены провода с двух сторон, но у этого переключателя был только один провод.

Понятно, что этот переключатель мог быть только чьей-то глупой шуткой. Убедившись в том, что он не должен работать, мы щелкнули им. Компьютер моментально сломался

Представьте себе наше крайнее изумление! Мы списали это на совпадение, но тем не менее вернули переключатель в более волшебное положение перед тем, как запустить компьютер снова, и больше его не трогали.

Год спустя я рассказал эту историю еще одному хакеру, Дэвиду Муну. Он посмеялся надо мной и выразил сомнения в моем здравом уме, обвинив меня, в вере в сверхъестественную силу этого переключателя. В доказательство своих слов я показал ему этот волшебный выключатель, все еще привинченный к корпусу шкафа с подключенным к нему только одним проводом, оставленный в положении больше магии. Мы внимательно изучили переключатель и обнаружили, что другой конец провода был подключен к контакту заземления. Это явно выглядело вдвойне бесполезным, он не только не работал электрически, но и был подключен к контакту, который, в любом случае, ни на что не мог повлиять. Итак, мы щелкнули выключателем.

Компьютер снова сломался

На этот раз мы побежали за Ричардом Гринблаттом, бывалым хакером из Массачусетского технологического института, который работал неподалеку. Он никогда раньше не замечал этого выключателя, но когда осмотрел его, тоже пришел к выводу, что он бесполезен, и решительно откусил провод. Затем мы перезапустили компьютер, и с тех пор он работал без проблем

Мы до сих пор не знаем, как выключатель ломал машину. Существует теория, что цепь рядом с выводом заземления была на пределе, и щелчок переключателя изменял электрическую емкость достаточно для того, чтобы нарушить цепь, когда через нее проходили импульсы с длинной в миллионные доли секунды.

Этот выключатель все еще валяется у меня в подвале. Возможно это глупо, но я держу его в положении большей магии.

Добавлено в 1994 году.

С тех пор было предложено еще одно объяснение этой истории.

Корпус переключателя был металлическим, а неподключенная сторона переключателя была привинчена к корпусу компьютерного шкафа (обычно корпус подключается к отдельной клемме заземления, но бывают исключения). Таким образом корпус выключателя был соединен с корпусом компьютера, который, предположительно, тоже заземлен. Заземление цепи внутри машины не обязательно имеет тот же потенциал, что и заземление корпуса, поэтому щелчок переключателя соединяет заземление цепей компьютера с землей корпуса, вызывая падение/скачок напряжения, которое перезагружает машину. Вероятно, это было обнаружено кем-то, кто на собственном горьком опыте, выяснил, что между ними существует разность потенциалов, а затем приделал переключатель в качестве шутки.

Хакерский фольклор МТИ



В одной конторе, где я в свое время работал, был один товарищ.

Трубку домофона в той конторе повесили у двери, к двери он сидел ближе всех, но бегать на каждый звонок ему было лениво.

Как он решил эту проблему? Он подключил контакты кнопки домофона, открывающей дверь через реле к флоппи-дисководу, расшарил доступ к диску A:, вывел всем ярлычки Открыть дверь.
После этого любой работник мог открыть дверь по локальной сети.

Фольклор

В одном закрытом военном НИИ проводили инвентаризацию и наткнулись на описание оборудования, которое никто не мог опознать. В Книге учета оно было записано как соком 50 хэ. Раз оборудование стоит на учете, его надо найти и проверить, тем более, что оценено оно было в заметную сумму условных единиц. Народ долго ломал голову, пока одному научному сотруднику не пришло в голову простое решение этого ребуса. Учетом занималась весьма пожилая женщина, без высшего образования, не знающая никаких языков, кроме русского. Потому, привод для CD-ROM, 50-скоростной, она записала как поняла, то есть соком 50 хэ.

Константин В.

Однажды, когда я работал в одной небольшой фирме, в нашем кабинете стали проводить инвентаризацию и всех попросили выйти, потому что нужно было наклеить инвентарные номера на всю мебель и оборудование, а мы им мешали. Мы решили совместить приятное с полезным и пошли обедать.

Вернувшись с обеда, мы обнаружили, что ни одна мышка не работает. Причина стала очевидна, когда я перевернул свою кверху брюшком. Ну куда еще можно наклеить инвентарный номер на мышь? Конечно же поперек отверстия с шариком!

Константин В.

В одной компании был МФУ Xerox, и у данного устройства существовала полезная особенность умение отсылать отсканированные документы на емейл. Для этого ему, как ни странно, нужна учетная запись на почтовом сервере, ибо отсылает он по SMTP. Меняли почтовый сервер, часть учетных записей мигрировали, а часть решили просто пересоздать. В процессе создания новой учетки для МФУ полезли на старый сервер уточнить login и обратили внимание на папку с входящими письмами. С сервера адский агрегат почту не забирал, так что скопилось ее порядка пятидесяти мегабайт.

Оказалось, что народ ведет активную переписку с МФУ, пишет ему Спасибо! и Благодарю за документы!. Особенно запомнилось сообщение одной сотрудницы: Спасибо, скан договора получила, жду от Вас приложение 2

Фольклор

Был случай, когда студентам, изучающим искусственный интеллект, дали задание написать самообучающегося бота для 3д-шутера. Студенты справились с заданием и запустили ботов в локалку, чтобы они за ночь наловчились убивать друг друга. Утром зашли в сетку и стали тестировать своих ботов. Выяснилось, что живых игроков выносят в первые же секунды, и выжить нет ни единого шанса. Когда стали смотреть логи, оказалось, что уровни в игре были сделаны небрежно, между текстурами были зазоры, которые не бросались в глаза игрокам, но были обнаружены ботами, и позволяли им прятаться внутри стен, проходя в любое помещение и убивать игроков, не давая им обнаружить себя.

Фольклор



Друг работает на складе комплектующих для компьютера.

Им пришёл заказ из СНБ на 100 модулей оперативной памяти. Вы представляете себе сто оперативок? Упаковали их компактно в коробочку 60 на 40 сантиметров. Приезжает представитель СНБ, у них с менеджером происходит диалог, после которого менеджер вползает в конвульсиях в кабинет шефа, вручает ему коробку с памятью и просит выйти самого.

Шеф выходит на крыльцо. Там стоит вышеупомянутый представитель, который показывает на КАМАЗ С ПРИЦЕПОМ!.. и выдаёт: Я тут машину подогнал, если этого не хватит, то мы ДВЕ ХОДКИ СДЕЛАЕМ!..

Шеф не растерялся, протягивает представителю коробочку и просит подержать. Сам подписывает документы, стоит и улыбается. Представитель начинает нервничать: Где же товар, у меня люди ждут, ЗАГРУЖАТЬ НАДО!.

Шеф: Он у вас в руке.

Фольклор



Мой брат живет в соседнем штате и уже достал просьбами помочь ему с компьютером по принципу тыжпрограммист. Некоторые из звонков в семейную службу техподдержки были болезненные как лечение у стоматолога. Ему казалось, что в его компьютер попадают вирусы и трояны, после чего он звонил мне. Он мог часами держать меня на телефоне, заставляя чинить ему компьютер.

Однажды я решил эту проблему раз и навсегда.

Тебе надо зайти в Гугл
Как мне это сделать?
Откройте свой браузер, введите Google и нажмите Enter.
Что за браузер? Как я могу это сделать?
Это, с чего ты смотришь что-либо в Интернете
О Он только что открыл Word? Так и надо было?

И в таком духе разговор продолжается больше часа. Внезапно мне в голову приходит дикая идея. Последовательно я подвожу его к тому, чтобы загрузить и установить VNC. Затем заставляю его посетить несколько сайтов по компьютерной безопасности, чтобы напугать его последствиями беспечного поведения в интернете, все время читая лекции на эту тему.

Я: Интернет действительно опасное место. Ты должен быть осторожен. Очень осторожен. Есть хакеры, которые хотят взломать твой компьютер. Если они заразят твой компьютер, то загрузят на него хакерские программы, которые будут делать всякие неприятные вещи. Они могут украсть твои пароли или получить доступ к банку и кредитным картам!

Одновременно с этим я через VNC случайно открываю и закрываю окна, захожу на разные сайты.

Я: Они даже могут захватить твой компьютер, превратив его в бота, которым ОНИ будут управлять. Я слышал рассказы о людях, к которым приходили из ФБР, потому что их компьютер был захвачен хакерами, и использовался для атак на Белый дом или Пентагон. Бедные люди даже не был в курсе, что их взломали

При этом я открываю и закрываю все больше окон.

Он: Эй! Я не уверен, что происходит, но мой компьютер ведет себя странно. Он пытается самостоятельно выйти в Интернет!
Я: Ой-ой. Это плохо! Ты уверен, что печатаешь не слишком быстро? На всякий случай запусти антивирус. Если ты не сможешь этого сделать, то это очень плохо.

Он пытается, но я мешаю движению его мыши. Наконец я позволил ему запустить программу, и как только она открылась, то я сразу закрыл ее.

Он: Я начинаю волноваться. Я не знаю, что происходит! Я ничего не могу сделать на своем компьютере!!!

А я открываю командную строку и запускаю команды: IPCONFIG, netstat, tracert whitehouse.gov и тд.

Я: Вау что ты сделал?! Выглядит очень серьезно. Похоже, твой компьютер был атакован Может быть, хакер пытается проникнуть в него. Возможно, тебе придется отключить его. Похоже, они пытаются добраться до твоего банка или того хуже

При этом начинаю набирать:

Access: Pentagon Classification TS5
PASSWORD REQUIRED: ******
FAILURE 1 NOTED: Alert sequence
Delta Alpha Charlie initiated : IP TRACKING LEVEL 1 PRIORITY INITIATED
WARNING - PASSWORD FAILURE 2
ALERT TEAM NOTIFIED: FINAL PASSWORD FAILURE
Security Breach detected. Tracking completed. IP ADDRESS confirmed. Response Team dispatched. Address Confirmed: Illegal security breach confirmed. Trace complete. Team dispatched - 2123 Main street: Perpetrator confirmation - John Smith.


Естественно, я использовал его реальный домашний адрес.

Я продолжал пугать его, набирая вышеуказанное, но он начал меня перебивать

Ой, чувак, это действительно очень плохо Они взламывают Пентагон. Что мне делать. Что делать?!

Я намереваясь действовать слишком медленно для его удобства.

Ой, ты должен запустить антивирус.
ПОМОГИТЕ! Они знают, кто я. Что мне делать?!
Ну, я бы посоветовал выключить компьютер, положить его в коробку и вернуть в магазин!
Наконец я уже не смог сдерживать смех и спалился, а потом объяснил ему, что я делал. Почему-то это не показалось ему настолько смешным, как мне. Но с тех пор мне не звонили как тыжпрограммисту!

Комментарий к статье



Наверное, худшая история, которую я могу вспомнить, помимо обычной головной боли от пользователей, была о том, как мне пришлось провести исследования активности одного пользователя в сети. Было показано, что этот человек генерирует очень большой трафик во второй половине дня и замедляет работу всего отдела. После нескольких минут изучения логов я обратил внимание на название одного из его часто посещаемых сайтов. Уже не помню конкретный адрес, но то был сайт, посвященный КРУПНМ женщинам. Я передал эту информацию своему руководителю, который передал ее дальше, и скоро я получил ответ от начальника моего босса, что им нужны конкретные примеры того, на какие типы сайтов он заходит, со скриншотами.

Остаток дня я никогда не забуду Если бы у меня под руками был отбеливатель, я бы залил его в свои глаз сразу, как только он зашел на тот сайт. Очевидно, этот джентльмен проводил 80% своего времени, просматривая очень сомнительные материалы в офисе.

После сбора снимков экрана в течении двух часов я связался с начальником моего босса, чтобы показать ему свое расследование

Позже он сказал мне, что они поговорили с тем сотрудником, и он уволился.

110 != 220

Это был мой первый год в ИТ, и мне пришлось менять компьютер, который управлял огромной сушилкой для древесины. Мне не очень много лет, но тогда многие компьютеры работали под DOS.

Я позвонил в Германию, в компанию по производству печей, нашел человека, который владел английским, получил спецификации, собрал снаряжение и уехал к заказчику, который находился за 200 миль. После резервного копирования предыдущей системы (на дискеты!) я вытащил огромную сетевую карту из старого компьютера, вставил в новый, подключил питание к ИБП и нажал кнопку включения.

БУМ

Голубой дымок из перегоревшего блока питания С побелевшим лицом я позвонил начальнику, рассказал ему обо всем, что я сделал, и к чему это привело.

Не переживай, щит хепенс, просто зайди в компьютерный магазин в получасе езды, купи новый блок питания и попробуй еще раз. Да, и удали эту чудовищную сетевую карту, прежде чем снова включишь питание!.

Быстро съездив до магазина и обратно, я возвращаюсь с новым блоком питания, заменяю его, снимаю сетевую карту и снова нажимаю кнопку питания.

БУМ

Еще больше голубого дыма, и мое лицо побелело еще сильнее. Я перезваниваю своему боссу: Опять что-то не так с вашей установкой. Через несколько минут, обсудив с ним все по телефону, мы пришли к выводу, что компьютер собран правильно, а проблема в чем-то другом.

Куда ты подключил шнур питания?
К ИБП
Хммм А чьего он производства? Ты не знаешь? Написано по-немецки?
Да
Тогда вернись в магазин, купи новый блок питания и поставь красный переключатель на задней панели на 220В. Перезвоните мне, когда печь снова заработает.

Вот так выяснилось, что в Германии техника работает на 220В. Думаю, 19-летний парень из Канады, которым я тогда был, мог этого не знать.

Из комментариев к статье



Когда я только начинал свою карьеру в сфере IT, и мне сказали, что один VIP-пользователь никак не может подключиться к VPN, попросили помочь. На его рабочем компьютере все было в порядке, поэтому я попросил пользователя лично показать мне, что он делает. Он достал свой токен RSA, ввел код с него и вошел в систему.

Однако этот пользователь не первый раз жаловался эту проблему, и я был не первым, кто пытался ему помочь. Я попросил его рассказать по шагам, что он делает перед тем, как у него не получается зайти в сеть.

Сначала, я достаю свой ноутбук, подключаю сетевой кабель, подключаюсь к Интернету из дома. Потом запускаю VPN-клиент, вытаскиваю этот листок с кодом и набираю его

Оказалось, что он записывал код с токена RSA перед тем, как уйти домой, а сам токен оставлял на работе, потому что эта штука была довольно дорогой, и он не хотел ее терять. Я объяснил, что номер все время меняется, и ему нужно всегда носить его с собой. Проблема с VPN была решена.

Комментарий к статье

Одна из компаний, поддержкой которых мы занимались на моей прошлой работе, была университетская полиция. И вот однажды моему коллеге позвонил начальник полиции и сообщил, что что-тоне так с подключением к сети Ethernet на его новеньком ноутбуке. Мы быстро подъехали, чтобы взглянуть на его ноутбук. Проблема была очевидна!

Каким-то образом (ядо сих пор не знаю, как у него хватило силы) начальник полиции вставил кабель Ethernet в разъем модема RJ-11. И вставил его так сильно, что треснул корпус вокруг разъема.

Комментарий к статье

Несколько лет назад мне позвонил один пользователь и пожаловался, что у него проблемы с печатью на принтере в его кабинете. Я зашел в настройку Принтеры WindowsXP и увидел, что принтера там нет.

Я подошел к его столу, чтобы проверить соединение, но обнаружил, что его рабочая станция не подключена к принтеру.

Зачем мне это нужно?, он спросил, Это же ЛАЗЕРНЙ принтер!"

Комментарий к статье



Этот было середине 90-х, в старые добрые времена DOS. Я работал в очень большом банке и оказывал поддержку пользователям по всему штату. Обучение сотрудников там не одобрялось, и в бюджете не было предусмотрено, поэтому у нас были здания заполненные людьми, пытающимися понять, как заставить работать их компьютеры. Одна дама работала в налоговом отделе, лет ей было 190, и она использовала компьютер только потому, что была вынуждена (опять же без обучения!). Я настроил для нее систему и сделал ее максимально удобной для пользователя, насколько это вообще было возможно в DOS. У нее было простое меню с тремя вариантами, один из которых запускал налоговую программу.

Однажды она позвонила мне очень сильно раздраженная: На моем экране ничего нет!. Не имея в своем распоряжении никаких диагностических инструментов, кроме своего воображения, я начал использовать ее как свои глаза.

Посмотрите на монитор, ту штуку, которая похожа на телевизор, горит ли зеленый светодиод?
НЕ ЗНАЮ
Посмотрите справа от телевизора, 2 дюйма вниз и 1 дюйм направо.
Есть зеленая лампочка.

Я еле удержался от комментариев, и мы повторили этот процесс для компьютера, с аналогичными сложностями в переводе с айтишного языка на понятный ей. После выяснения того, что все действительно было включено и работало правильно, я снова обратил внимание на монитор. Мог ли он сгореть?

Хорошо, я хочу, чтобы вы посмотрели в телевизор. Вы видите что-нибудь похожее на светящиеся оранжево-желтые буквы где-нибудь на стеклянной части телевизора?
О да, там написано 'C: ->'

Я подумал объяснить ей, что она смотрела на приглашение DOS, но решил пропустить такие подробности.

Наберите MENU, нажмите Enter и расскажите мне, что происходит
Ничего.
Есть новые яркие символы?
Да: Bad command or filename C:->.

Несколько попыток запустить приложение Menu не увенчались успехом, поэтому я подумал, что, возможно, приложение было повреждено. После внутренних стенаний о том, что будет дальше, я сказал:

Давайте попробуем запустить приложение Tax без меню. Я хочу, чтобы вы набрали: CD (space) TAX, нажмите Enter и расскажите мне, что произошло.
Ничего! На экране ничего нет!

С растущим возбуждением я прошу:

ПОСМОТРИТЕ НА 1/2 дюйма от того места, где остановились ваши глаза и прочтите чертовы светящиеся символы!
Bad command or file name".

Я был в недоумении Потом еще подумал несколько минут, и мне в голову пришла идея.

Прочитайте по буквам то, что вы только что набрали
S E E D E E S P A C E T A X"

Именно в тот момент своей карьеры я понял, для чего на самом деле нужна кнопка отключения звука. Когда я отключил свой телефон, то с криком ударился головой об стол!

Комментарий к статье



У меня было много такого, чего я уже не вспомню, но есть один случай, когда одна девушка сообщила: На мониторе моего компьютера утка.

Служба поддержки 1-го уровня удаленно проверила ее машину и не нашла вредоносных программ или приложений, которые могли бы вызывать такое поведение. Они уже собирались прислать мне компьютер, чтобы я физически проверил, но, прежде чем отдать мне свою машину, она заявила, что со всем разобралась.

Мне было очень любопытно, что же вызвало такую проблему, поэтому я спросил, что произошло

Она ответила, что вентилятор наклеил на ее монитор стикер с уткой, и она просто не заметила этого.

Комментарий к статье

Однажды вечером нам позвонили из небольшой фирмы примерно в 70 милях от нас. Перед этим мы продали им новый принтер, все, что им нужно было сделать установить драйверы и подключить устройство. Ничего особенного.

Но они позвонили мне и сказали, что компакт-диск не помещается в дисковод. Читая наклейку на диске, они сказали, что поняли проблему. На диске было написано, что он предназначен для MAC, а мне нужно было отправить им диск для Windows, так как компакт-диск от MAC не влезет в привод. Дело было срочное и я поехал к ним в офис.

Я понял проблему сразу, как только вошел в офис, потому что на верхней части компьютера были маленькие резиновые ножки. Решение? Переверните компьютер и теперь CD отлично подходит!

Комментарий к статье

Было дело, в техподдержку позвонила женщина позвонила и сказала, что каждый день она сохраняет свою базу данных на дискете, а на следующий день дискета всегда пуста.

После того, как несколько дней мы просили ее проверять целостность данных в резервной копии, и все было в порядке, но на следующий день снова все исчезало, мы отправили к ней технического специалиста.

Что он увидел?

После сохранения данных на диск 5 1/2 она прикрепляла его к своему металлическому шкафу с помощью промышленного магнита.

Комментарий к статье



В один момент мне было необходимо срочно проложить четыре десятка проводов витой пары на расстояние в сто метров. Большая часть дистанции проходила над навесным потолком на трёхметровой высоте. Поняв, что для моих единственных в конторе админских плеч решение задачи в приемлемые сроки является непосильным, я принялся терзать шефа на предмет привлечения сторонних монтажников, и тот, скрепя сердце, согласился. Я разработал техзадание, разослал по разным конторам и стал ждать.

Одно из предложений сильно выделялось из общей массы. Ребята утверждали, что работу они выполнят всего за один день, причём втрое дешевле, чем любой из конкурентов! На всякий случай перезвонил и уточнил, правильно ли они поняли задание. Ответили, что поняли прекрасно, а скорость и дешевизна объясняется тем, что в работе используется кабелеукладчик. Я был заинтригован. С кабелеукладчиками имел дело в армии и решительно не представлял, каким образом данный девайс можно приспособить к прокладке витой пары под фальшпотолком.

В назначенный день прибыли всего два монтажника со стремянками и инструментами. Наблюдая за процессом разгрузки, я с нетерпением ждал чудо-агрегата, способного автоматизировать процесс. Агрегата так не дождался, зато последней из микроавтобуса была выгружена некрупная такса. Не успел я удивиться по поводу появления животного, как мне объяснили, что это и есть таинственный кабелеукладчик.

В комплекте к таксе шел специальный костюмчик с ручкой вдоль спины для переноски, сбруя на голову со светодиодным фонариком и шлейка. Прокладка кабеля осуществлялась путём прикрепления его к шлейке и запуска таксы в труднодоступное место. Надрессированное животное шустро мчалось на звук голоса или свет фонаря, волоча за собой провод. Потолок собаку выдерживал, мощности же хватало метров на пятьдесят.

Скорость прокладки в длинных и труднодоступных участках была просто фантастической. Такса резво носилась в одну сторону по верху, а обратно по коридору, пугая женскую часть персонала. Даже ЧП в виде выпавшей панельки потолка не повлияло на её настроение: протягиваемый провод сыграл роль страховочного троса, и собачка плавно опустилась на пол. Ребята сказали, что к таким ситуациям кабелеукладчик приучен.

Смех смехом, но такса на полном серьёзе стояла у ребят на балансе фирм. Мне были продемонстрированы документы. Работу дружный коллектив действительно выполнил менее, чем за день, причем без предварительного разматывания кабеля и, соответственно, без обрезков. Правда, работа нашей конторы полностью встала: всё население сбежалось посмотреть за работой кабелеукладчика.

Фольклор

Мы поставили пиво в холодильник и ждем ваших историй


Победителя определим через неделю, 10 марта.

Напоминаем правила:

  • Ваша любимая история, личная, рассказанная другом за бутылочкой пива, прочитанная когда-то
  • Баночка за каждую историю
  • Ящик эля за самую заплюсованный историю в комментариях


Подробнее..

Хватит отдавать Гуглу ваши данные. Десять альтернатив для Google Analytics

04.03.2021 16:23:55 | Автор: admin


4 сентября 1998 года Сергей Брин и Ларри Пейдж основали компанию Google. На заре своего существования Google представляла собой фирму одного продукта, притом продукт получился настолько крутым и классным, что быстро пошатнул рыночные позиции конкурентов. Однако перенесемся на 23 года вперед. Современный Google это уже давно не поисковая система. Вернее, не только поисковая система. Это огромная транснациональная и очень эффективная рекламная платформа, целый завод по производству денег, использующий в качестве сырья пользовательские данные. Но стоит ли делиться с этой платформой теми самыми данными? На этот счет есть разные мнения.

В качестве рекламной платформы мегакорпорация Google мегаэффективна. Собранные данные о пользователях, полученные с помощью поисковика и собственного браузера Chrome, позволяют показывать юзерам таргетированную рекламу, соответствующую их интересам. Значительный объем сведений корпорация получает благодаря популярности мобильной платформы Android, которая по разным подсчетам занимает до 72% рынка. Но не меньший интерес для рекламных сервисов представляют сведения о посещенных юзерами сайтах, которые собираются, в том числе, с помощью скриптов Google AdSense и трекеров Google Analytics. Последние можно назвать поистине уникальным инструментарием для сбора бигдаты о населении интернета: администраторы, устанавливающие на сайты эти скрипты, совершенно бесплатно получают довольно подробные и полезные отчеты об аудитории своих ресурсов, а Google, в свою очередь, собирает и аккумулирует ту же статистику в рекламных целях. Все довольны.



Можно смело утверждать, что большинство подключенных к Интернету жителей нашей планеты так или иначе пользуется сервисами Google, что в 2020 году позволило корпорации собрать выручку порядка 180 миллиардов долларов. Значительную долю в этой сумме Google заработала за счет рекламы. И если с остальными сервисами все более или менее однозначно: раз вы используете их, вы неизбежно делитесь с Google информацией, то от Google Analytics вполне можно отказаться. Благо, существуют альтернативные службы, способные предоставить владельцам сайтов развернутую статистику, их можно использовать и в качестве замены Google Analytics, и совместно с ней. Рассмотрим и сравним самые популярные из подобных сервисов.

Рanelbear


Сайт: https://panelbear.com/
Тип сервиса: Коммерческий с бесплатным тарифом



Сервис предоставляет аналитику для веб-сайтов в реальном времени. К услугам пользователей анализ трафика (объем, источники, география и т.д.), оценка скорости загрузки сайта и его отдельных страниц, возможность отслеживания различных событий. Помимо этого сервис генерирует и отображает предупреждения о возможных проблемах на отслеживаемом интернет-ресурсе: низкая скорость загрузки, высокое количество отказов, и т.п. Отчеты со статистикой сайт автоматически отправляет администратору по электронной почте через заданные промежутки времени.

Рanelbear не использует cookies, и, по утверждениям разработчиков, заботится о приватности посетителей сайтов, на которых установлена данная метрика. При количестве просмотров страниц сайта менее 5000 в месяц можно воспользоваться бесплатным тарифом Рanelbear, если количество посетителей и просмотров больше, необходимо выбрать платный тариф стоимостью от $5.99 в месяц.

РostHog


Сайт: https://posthog.com/
Тип сервиса: MIT/Open Source с опциональными платными тарифами



Эта система аналитики написана на Python и распространяется под лицензией MIT. Исходные коды PostHog доступны для свободной загрузки на GitHub. По утверждению разработчиков, этим продуктом пользуется компания SpaceX Илона Маска, банк Тинькофф, авиакомпания AirBaltic и множество других уважаемых клиентов.

С помощью PostHog можно собирать и анализировать статистику веб- и мобильных приложений, включая сведения об источниках трафика, о том, как пользователи взаимодействуют с сайтом или приложением включая визуализацию навигации, трекинг сессий и отслеживание конверсий. Вы можете развернуть PostHog на собственном сервере или в облаке с помощью общедоступных исходников, либо выбрать один из предложенных разработчиками тарифов и использовать систему аналитики, как сервис.

Hotjar


Сайт: https://www.hotjar.com/
Тип сервиса: Коммерческий с бесплатным тарифом



Этот сервис не просто предоставляет довольно подробную статистику об источниках трафика и посетителях сайта, но и довольно интересные визуализации карту кликов, показывающую области на сайте или в веб-приложении, где пользователи щелкают мышью чаще всего, запись движения курсора мыши пользователей на сайте, динамику прокрутки страниц, и т.д. Причем все эти активности можно просматривать для разных категорий посетителей: например, владельцев компьютеров, планшетов, мобильных устройств. Всю статистику можно скачать в виде наглядных отчетов.


Так выглядит карта нажатий на сайте с точки зрения Hotjar

Для некоммерческого использования Hotjar предлагает бесплатный тариф с ограниченными возможностями, а также целый ряд коммерческих тарифов для бизнес-аккаунтов.

Matomo


Сайт: https://matomo.org/
Тип сервиса: Open Source c коммерческим тарифом



Один из самых популярных сервисов веб-аналитики, в прошлом известный под названием Piwik. Разработчики сами позиционируют его, как бесплатную альтернативу Google Analytics с упором на безопасность и защиту данных пользователей. Исходные коды Matomo, написанные на PHP и распространяющиеся под лицензией GPL 3.0, доступны на GitHub.

Matomo предоставляет практически идентичный Google Analytics набор метрик, разве что разработчики утверждают, что при использовании их услуг клиент сам является владельцем собранных данных, и они гарантированно не утекут налево. Сервис бесплатен, но при желании можно воспользоваться коммерческим тарифом за 29 евро в месяц с размещением движка Matomo в облаке.

Heap


Сайт: https://heap.io/
Тип сервиса: Платный с бесплатным ограниченным тарифом



Еще одна платформа сбора статистстики для разработчиков мобильных и веб-приложений. Heap фиксирует активность пользователей и позволяет анализировать полученные данные для повышения конверсии: сегментировать пользователей по поведению, строить воронки продаж, оценивать монетизацию и отслеживать, какие маркетинговые каналы наиболее эффективны с точки зрения регистраций юзеров. Иными словами, Heap заточен под продуктовую аналитику. При этом сервис старается отслеживать и сохранять максимальное количество метрик, поэтому теоретически позволяет анализировать данные ретроспективно для тех событий и объектов, которые изначально не интересовали клиента Heap, но однажды вдруг зачем-то понадобились.

Для оценки приложений, насчитывающих 60000 и менее пользовательских сессий, можно использовать бесплатный тариф с рядом технических ограничений, разработчикам более нагруженных приложений придется платить.

Оpentracker


Сайт: https://www.opentracker.net/
Тип сервиса: Платный



Красивый сайт с выпрыгивающей из аквариума золотой рыбкой, видимо, решившей таким образом совершить роскомнадзор, предлагает нам подключиться к системе статистики реального времени, что бы это ни значило. Среди прочих стандартных функций вроде анализа трафика сервис позволяет маркировать различными способами зарегистрированных на сайте пользователей, идентифицировать посетителей по компаниям и провайдерам (на основе IP-адресов), и т.д. Несмотря на то, что в названии сервиса присутствует слово open, он платный, на выбор предлагается несколько тарифов. Халявы не предусмотрено.

Foxmetrics


Сайт: https://foxmetrics.com
Тип сервиса: Платный



Еще один коммерческий продукт, предназначенный в первую очередь для бизнеса. Foxmetrix представляет собой полностью управляемое хранилище данных масштаба предприятия, позволяющее собирать и анализировать информацию о пользователях и их поведении. Данные могут поступать в Foxmetrix из нескольких источников и обрабатываться как совместно, так и кластеризованно в этом, пожалуй, ключевое отличие этого решения от других аналогичных сервисов.

Среди предлагаемых инструментов различные схемы обработки информации, построение пользовательских моделей данных, сегментация собранной статистики и множество различных видов отчетов. Сведения о расценках на сайте не приводятся. Видимо, дорого.

Screpy


Сайт: https://screpy.com/
Тип сервиса: Платный



Сервис, базирующийся, по утверждениям его создателей, на технологиях искусственного интеллекта и машинного обучения. Предлагает вполне типичный набор инструментов: веб-аналитика, проверка Google Rank, мониторинг скорости загрузки страниц, анализатор трафика, HTML-валидатор, аудит сайта с использованием Lighthouse. Стоит это удовольствие от $9 в месяц, потенциальным пользователям предлагается бесплатный триал.

Проект в целом ориентирован на SEO, а не на аналитику, отсюда и несколько странный набор предлагаемых им дополнительных возможностей вроде подбора ключевых слов и поиска ошибок на сайтах, ведущих к его пессимизации в поисковой выдаче. Впрочем, ассортимент аналогичных SEO-инструментов можно найти в интернете и бесплатно, здесь они просто собраны на одном ресурсе.

Сontentsquare


Сайт: https://contentsquare.com/
Тип сервиса: Платный



Yet another платформа статистики, ориентированная на продуктовую аналитику и маркетинг. В ассортименте анализ источников трафика, поисковых запросов, оценка поведения пользователей, конверсий, эффективности посадочных страниц сайта, с разбивкой всего этого по времени и заданным сегментам. Аналитика визуализируется в виде красивых отчетов, графиков и диаграмм. В общем, Сontentsquare предлагает весь необходимый маркетологам инструментарий, чтобы продемонстрировать кипучую деятельность, собственную полезность, и при случае выбить из руководства еще более вкусный бюджет. Цен на сайте нет, зато есть предложение отправить их по запросу по всей видимости, прайс рассчитывается исходя из вашей крутизны и глубины кармана.

Woopra


Сайт: https://www.woopra.com/
Тип сервиса: Платный с бесплатным тарифом



Система аналитики, предлагающая простую интеграцию со множеством популярных технических решений, сервисов и порталов: Dropbox, Google Drive, Facebook, Azure, MailChimp, WordPress/WooCommerce, и другими. Позволяет отслеживать источники трафика, тренды в поведении пользователей, настраивать ретаргетинг, анализировать users retention и многое другое. Есть бесплатный тариф (до 500000 метрик в месяц с рядом других ограничений) и платные тарифы, стартующие от нескромных $349 в месяц и до свяжитесь с нами, если хотите, чтобы мы вас удивили.

Другие сервисы



Думаете, этими десятью проектами ассортимент доступных альтернатив Google Analytics? Да ничего подобного! Имя им легион. Вот еще несколько подобных сервисов на выбор:

Clicky (https://clicky.com/) сервис со страшненьким сайтом из 90-х, платный с бесплатным тарифом.
Open Web Analytics (http://www.openwebanalytics.com/) бесплатный с открытыми исподниками (GPL 2.0)
GoingUp (https://goingup.com/) платно-бесплатный сервис с уклоном в SEO
Сhartbeat (https://chartbeat.com/) сервис аналитики в реальном времени.
Gaug.es (https://get.gaug.es/) еще один сервис аналитики в реальном времени.
Indicative (https://www.indicative.com/) Инструмент веб- и мобильной аналитики с упором на сегментацию и визуализацию.
Statcounter (https://statcounter.com/) анализ трафика для сайтов.
Hitslink (https://www.hitslink.com/) аналитика в реальном времени, отчеты о трафике в социальных сетях и динамическая сегментация.
Parse.ly (https://www.parse.ly/) инструмент веб-аналитики в реальном времени с упором на отслеживание контента.
Loggr (http://loggr.net/) трекинг событий для сайтов и веб-приложений.
Rakam (https://rakam.io/) бесплатная опенсорсная платформа пользовательской аналитики, позволяющая создавать собственные аналитические службы. Интегрируется с любым источником данных (веб, мобильные устройства, интернет вещей и т. д.)
Metabase (https://www.metabase.com/) еще одна система аналитики.
LiveSession (https://livesession.io/) платформа аналитики с акцентом на User Experience.
Glassbox (https://glassboxdigital.com/) аналитика с упором на User Experience и трекинг действий пользователя.
Redash (https://redash.io/)- Опенсорсная платформа для сбора, анализа и визуализации данных.
Druid (https://druid.apache.org/) база данных для хранения аналитики и статистики. Open Source.
EDA (https://eda.jortilles.com/en/jortilles-english/) Система аналитики с открытым исходным кодром

Подробнее..

Перевод Как освоить Vim?

05.03.2021 12:10:54 | Автор: admin
Осваивать Vim это, пожалуй, страшно. Или, точнее, очень страшно. Речь идёт об изучении совершенно необычного подхода к редактированию кода, не говоря уже о работе с простым текстом. Многие несправедливо обвиняют, тех, кто выбирает Vim, в том, что они впустую тратят время.

Я со всей уверенностью могу заявить о том, что Vim позволил мне повысить эффективность в деле написания программ. Работать стало удобнее (ниже я расскажу об этом более подробно). Я никому не хочу навязывать Vim, но очень рекомендую освоить этот редактор всем, кто занимается программированием, работает в сфере Data Science, в общем тем, кто так или иначе пишет и редактирует некий код.



Если вам очень хочется узнать о том, стоит ли вам использовать Vim, и о том, кто и для чего им реально пользуется взгляните на этот материал (кстати, не позвольте его названию, Не пользуйтесь Vim, ввести себя в заблуждение). Ещё можете посмотреть это видео, которое, кстати, подготовил сам Люк Смит.

А теперь, учитывая всё вышесказанное, предлагаю поговорить о том, что такое, на самом деле, Vim!

Что такое Vim?


Отвечая на этот вопрос, я хочу ещё раз повторить то, что было сказано в самом начале статьи: Vim это редактор, реализующий совершенно необычный подход к редактированию кода, не говоря уже о работе с простым текстом.

В Vim имеется несколько режимов работы, переключение между ними приводит к изменению функционала клавиатурных клавиш (например, клавиша W в режиме вставки, что неудивительно, позволяет ввести букву w, а вот в нормальном режиме она позволяет перемещать курсор вперёд на одно слово). При таком подходе клавиатура используется и для ввода символов, и для перемещения по тексту. Другими словами при работе в Vim не нужна мышь.

Это очень хорошо в тех случаях, когда нужно постоянно переключаться между редактированием и просмотром кода. Обычно программисты именно так и работают. Если вы раньше никогда не пользовались Vim для работы с программным кодом, то вы даже не замечаете того, как много времени тратится на то, чтобы снять руку с клавиатуры и потянуться к мыши (или к трекпаду), затем на то, чтобы переместить курсор туда, куда нужно, и наконец на то, чтобы вернуть руку на клавиатуру и приступить к вводу текста (в общем тратится очень много времени).

Конечно, на то, чтобы привыкнуть к Vim, нужно некоторое время. И это не прямая замена какой-нибудь IDE или редактора вроде VS Code. Но можно сказать, что Vim позволяет тому, кто умеет им пользоваться, значительно ускорить работу с кодом. Кроме того, интересно то, что его более простым аналогом является Vi стандартный текстовый редактор большинства Unix-подобных систем, работающий в терминале.

Как научиться работать в Vim?


1. Используйте vimtutor


Меня не удивляет то, что в каждом руководстве по Vim рекомендуется начинать изучать этот текстовый редактор с vimtutor. Поэтому я, без зазрения совести, поступлю так же. Нет нужды играть ни в какие Vim-игры (хотя они и довольно интересны), или прибегать к программам, помогающим запоминать бесчисленные клавиатурные сокращения. Надо просто установить vimtutor и, когда найдётся 10-15 минут свободного времени, прорабатывать этот официальный учебник по Vim. И не пытайтесь сразу же запомнить все клавиатурные сокращения Vim; вы запомните их постепенно, снова и снова проходя уроки vimtutor.

Хочу отметить, что Windows-пользователям я рекомендую использовать WSL (Windows Subsystem for Linux, подсистему Windows для Linux) и для прохождения vimtutor, и, в целом, для работы с Vim. Лично я в Windows с Vim не работал, поэтому не могу обещать того, что при работе с ним в этой ОС всё будет точно так же, как в Linux.

2. Постоянно пользуйтесь Vim


Практика это путь к совершенству. Это главный принцип, которого стоит придерживаться при изучении чего-то нового. Изучение Vim не исключение. Поэтому, пока вы изучаете Vim с помощью vimtutor, пользуйтесь этим редактором для решения реальных задач.

Используйте Vim как можно чаще. Нужно просмотреть текстовый файл? Запустите Vim. Хотите что-то по-быстрому изменить в Python-скрипте? Примените Vim. Делаете какие-то заметки? Делайте их с помощью Vim. В общем, полагаю, вы меня поняли. И каждый раз, когда работаете в Vim, всегда задавайтесь вопросом о том, какова наиболее эффективная последовательность нажатий на клавиши (то есть наиболее короткая последовательность), позволяющая решить текущую задачу.

И попутно постарайтесь сократить использование мыши.

3. Интегрируйте с Vim всё что сможете


Используйте клавиатурные привязки Vim везде, где это возможно. Начните делать всё, что сможете, в стиле Vim. Например, если вы пользуетесь браузером, основанным на Chromium (Chrome, Brave, Edge), или браузером Firefox, подумайте об установке расширения Vimium, которое позволяет пользоваться в браузере клавиатурными сокращениями Vim, отвечающими за перемещение по документу (H, J, K, L и так далее).

Если вы пользуетесь для работы с кодом некоей IDE найдите плагин или расширение для добавления Vim-привязок в соответствующую среду. Например, пользователи PyCharm (или любой IDE от JetBrains) могут воспользоваться ideavim. А пользователи VS Code (в 2021 году этот инструмент уже ближе к IDE, чем к обычным текстовым редакторам) могут прибегнуть к расширению VSCodeVim.

В Jupyterlab можно включить привязки Vim для встроенного текстового редактора путём установки jupyterlab-vim, что позволит полностью эмулировать Vim в ячейках блокнотов.

Постарайтесь органично интегрировать Vim в свою рабочую среду и несколько недель поработайте по-новому. Я могу говорить о том, что после нескольких VSCode-сессий в стиле Vim мне стало гораздо удобнее пользоваться этим редактором. А ещё я очень рад избавлению от мыши!

4. Перенастройте клавишу Caps Lock (но это необязательно)


Самая бесполезная клавиша, расположенная в самом лучшем месте клавиатуры. Именно так можно охарактеризовать клавишу Caps Lock. Поэтому советую превратить Caps Lock в Escape. Если вы интересуетесь Vim, то уже должны знать о том, что клавиша Escape используется в Vim для переключения режимов. Я очень советую тем, кто стремится к максимальной эффективности, воспользоваться вышеописанной модификацией.

Пользователи Windows и WSL могут использовать uncap программу, которая превращает клавишу Caps Lock в Escape.

Пользователям macOS в плане переназначения клавиш повезло они могут решить эту задачу, прибегнув к системным настройкам.

Если вы работаете в Linux настроить всё как надо вам помогут StackOverflow и Google. Лично я (заслуженный пользователь Arch Linux) использую утилиту setxkbmap, с помощью которой делаю из Caps Lock ещё одну клавишу Escape. А потом включаю автозапуск утилиты при запуске системы:

setxkbmap -option caps:escape

5. Глубже изучите Vim


После того, как вы привыкнете к Vim и немного его освоите, придёт время для более глубокого освоения этого редактора ради дальнейшего повышения эффективности своего труда. Ниже я, основываясь на собственном опыте, привожу список самых полезных (и, пожалуй, уникальных для Vim) команд, применимых в нормальном режиме работы:

  • ZZ сохранить документ и выйти из Vim. Красивая команда.
  • zz, zt, zb прокрутка текста, перемещающая строку с курсором, соответственно, в центральную, в верхнюю или в нижнюю часть области просмотра.
  • Ctrl+u, Ctrl+d прокрутка области просмотра вверх или вниз на полстраницы.
  • ciw (Change Inside Word) удаление текущего слова и автоматический переход в режим вставки.
  • C удалить текст от позиции курсора до конца строки и перейти в режим вставки.
  • dt<char> (Delete To <character>) удалить текст от позиции курсора до следующего вхождения указанного символа.
  • ~ (тильда, на стандартной клавиатуре вводится клавишей, находящейся под Escape) переключение регистра (верхний/нижний) текущего или выделенного символа.
  • . (точка) повтор последней команды Vim.
  • ggvG= (перейти в начало файла, войти в визуальный режим, выделить весь текст до конца, выровнять выделенные строки) автоматическое выравнивание текста во всём файле.

Освоение подобного списка команд может показаться неподъёмной задачей. Но помните о том, что стоит стремиться к изучению нового через практику, а не через запоминание. Эти команды Vim, если взглянуть на них с другой точки зрения, показывают то, что этот редактор способен дать нам мощнейшие возможности, доступные без применения мыши или контекстных меню.

Если вас интересуют другие команды Vim посмотрите это замечательное и довольно длительное видео, демонстрирующее прохождение уроков vimtutor, которое записал Вим Дизель (шучу это всё тот же Люк). Тут собрано множество полезнейших советов по Vim.

Итоги


Вероятно, сейчас вы уже достаточно хорошо освоили Vim и значительно повысили свою скорость работы с кодом. И вы наконец сможете похвастаться перед пользователями Reddit или перед коллегами своими отточенными навыками редактирования текстов, когда в ходе работы вам не приходится убирать руки с основной части клавиатуры. Когда вы достигнете подобного уровня, вы можете развиваться в сфере Vim и дальше. Например в следующих направлениях:

  • Можно установить Neovim и поэкспериментировать с ним (это отрефакторенный форк Vim, рассчитанный на высокий уровень расширяемости и на поддержку графического интерфейса).
  • Можно перенести функционал Vim в терминал или интерпретатор командной строки, воспользовавшись vim-airline.


Vim-airline, тема violet (источник)

  • Можно попробовать некоторые из популярных Vim-плагинов.

Желаю всем, кто дочитал до этого места, наслаждаться будущим, наполненным благами Vim (и освободиться от власти мыши или трекпада).

Пользуетесь ли вы Vim?

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru