iborzenkov
0

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

iborzenkov
0

Сам чуть больше года проработал на кипре, тоже в IT.
По поводу климата согласен — в августе жарко, зимой холодно. Транспорт тоже попа, плюс у меня нет водительского, я снимал квартиру в получасе ходьбы от работы, зато похудел и приучился к прогулкам. А вот в горах кстати вполне красиво — с друзьями брали машину и ездили — правда весь кипр за пару дней, на северный не ездили.
С банками — согласен bank of cyprus == сбербанк — такая же гадость, меня вообще позвали со странным вопросом "а что это вы каждый месяц перечисляете деньги риэлторской компании?", посмотрел как на идиотов.
То что налоги в экселе — это же хорошо, это в рашке нужно 1С и налоговое законодательство закопать.
Еще могу добавить про море — оно там как в Москве красная площадь — исключительно для туристов похоже :)

iborzenkov
0

Это согласен — UI все-таки там не модный.

iborzenkov
0

Похоже недостатки дженкинса так притянули, что уши оторвали :)

iborzenkov
+24
на легковесный node js

Поперхнулся…
В течении последних двух лет назвать js легковесным…
Слезть с php на ноду из-за легкости — месье знает толк в извращениях.

iborzenkov
–1

Нормальный аналог уже есть — ssh и конфиги а также ansible
Тут ситуация как с говнофорумами на php — те кто знают как сделать нормально им не нужно

iborzenkov
0

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

iborzenkov
0
Мы для тестов использовали вместо id data-test аттрибут, выбрать по нему можно легко, в своем пространстве — ни с чем не конфликтует, скорость выборки как-то пофигу на тестах.
iborzenkov
0
Абстрагирование оно получается из-за архитектуры — потому что orm должна поддерживать много баз и она строит запрос сама — в результате получается что все равно делается драйвера с одним интерфейсом.

Вот именно маппинг на объекты, а потом обновление всего после того как поменяли объекты.
Как-бы orm могут разбивать объекты и таблицы и автоматически подтягивать вложенные по связям.
В 90% легких запросов у нас уже есть готовый код, а в случае тяжелых — ну выявятся и оптимизируются.
iborzenkov
0
Ну так как-бы если на некоторых то это решается привязкой mac-ip
iborzenkov
+1
Тут уже высказались выше по поводу всего этого.
Я хочу спросить по поводу шлюза — чем же вам так не понравился DHCP?
iborzenkov
0
Тогда уж fetch вместо xmlhttp
iborzenkov
+3
У меня работает на домашнем компе, на рабочем, на ноуте, на старом ноуте. На винде не работал уже лет наверное 8, обновлял на живую с дебиана на убунту. Переставлял систему только один раз когда физически умер системный винчестер. Ну были еще переустановки при переезде 32-64 бита.
Скажите, что я неправильно делаю?
iborzenkov
0
Ну восновном там описаны базовые вещи для всех проектах на php и капитанство.
Ну собственно за это ларавель и не любят в частности — вот такие вот суслики, которые мнят себя агрономами.
Эффект Даннинга-Клюгера в чистом виде + хайп.
iborzenkov
0
Ну почему же? Вполне соответствуют среднему уровню Laravel программиста.
iborzenkov
+1
Ну вполне реально использовать шаблоны — как пример /lib/systemd/system/getty@.service и соответственно getty@tty1.service
Вполне себе используется во fleet на coreos.

update: Я буду обновлять страницу перед написанием комментария :)
iborzenkov
+3
Блин, ну теперь палочкой потыкайте systemd, он не обидется.
init не занимается конфигурацией сети, настройкой локали, синхронизацией времени, логами, dns.
этим занимаются
NetworkManager
systemd-journald
systemd-resolved (на который кстати та же убунта перешла только в 17.04)
systemd-timesyncd

это все отдельные процессы, которые могут быть заменены
и у всего этого гораздо меньше неожиданных мест чем у sysvinit
разумеется не идеально, но уж точно лучше sysvinit и upstart с которыми сравнивают
iborzenkov
+1
по умолчанию в rsyslog/syslog-ng если быть точнее
iborzenkov
+1
«теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service»
Именно что нет, это было в убунте 16.04 до его выхода в релиз — там как раз в альфе немного службы отваливались.
Нету ни sysV ни upstart, то что вы показали с upstart — остатки от пакетов, которые к 16.10 были почищены, потому что у них стояла задача поддержки, а не выпиливания всего.
service кстати не костыли, а врапер для тех кто привык, юзает он systemd
В вашем понимании полная поддержка это не установленная по умолчанию, и полностью рабочая система, а выпиленные все остальные?
Окей, тогда 17.04 вполне себе подходит — они полностью выпилили sysV, его даже в пакетах нет.

$ find /etc -name *upstart*
zsh: no matches found: *upstart*


dev / # du -sh /etc/init.d
428K /etc/init.d


И что вы хотите этим сказать? у systemd есть слой совместимости с sysV, а тогда не все пакеты перешли еще, сейчас в два раза меньше уже, и то с учетом поставленного стороннего.

А что вы не хотите про RHEL говорить?

CentOS Linux release 7.3.1611 (Core)
du -sh /etc/init.d/*
4.0K /etc/init.d/README
16K /etc/init.d/functions
0 /etc/init.d/jexec
4.0K /etc/init.d/netconsole
8.0K /etc/init.d/network

iborzenkov
0
А, дико извиняюсь, посмотрел на свою ubuntu 17.04
sysvinit в репе отсутствуют — только утилиты остались
upstart есть, но дефолтным его можно поставить только ручками
ну конфиги будут подчищать потихоньку из пакетов
iborzenkov
0
Целиком вы подразумеваете что выпилят поддержку всего остального?
Так этого не будет, если есть система инициализации в дистрибутиве — ее будут поддерживать.
Вот когда похоронят upstart и sysV то тогда и выпилят. Ну а так уже отдельные новые пакеты не пишут скрипты для sysV оставляя только файл для systemd.
iborzenkov
+1
Вы это, обновляться пробовали?
ubuntu — 16.04
debian — с jessie
rhel — с 7
Дефолтными между прочем, разумеется сохранив совместимость с sysV и upstart для убунты.
Арч даже поддерживает и гента только не по дефолту.

Вот честно давно чистый дебиан не юзал — все убунта, но уже около все на systemd без проблем, в начале разумеется он еще скрипты стартовал, сейчас ок, и centos на вертуалке проекта — там тоже systemd дефолтно, тут вот на работе хейтеры в ужасе, но они линкс только в виртуалках видели из под макоси, им простительно.
iborzenkov
+5
Кстати по поводу бинарных логов это вообще аргумент людей, которые «не читал но осуждаю»
В syslog systemd умел писать с самого начала, а сейчас вообще при установки syslog из пакетов он автоматически конфигурирует все что нужно в systemd. А с учетом того что syslog обычно устанавливается, то конфигурация с journal будет скорее всего только в контейнерах, для которых собственно он и отличный вариант
iborzenkov
+1
Разве? А разве третье слово не му*ки :-D
iborzenkov
–6
Немножко не в ту сторону
jQueryAngular 2 наше все :)
Fixed.
iborzenkov
+1
Не на некоторых, а на почти всех фреймворках есть public директория с точкой входа а весь код лежит выше.
Весь проект в корне — это обычно CMS, которые устанавливаются путем копирования по ftp, разумется про git там не слышали. Так что собственно поэтому у нас всего 0.6%
iborzenkov
0
Ну вобщем да, с контейнером еще можно жить, тут не спорю. Хотя на уровне ларавеля симфонийский контейнер не сложнее.
Blade некорректно обрабатывает include — в нем нельзя изолировать контекст
как пример — попробуйте в цикле вставить шаблон с переопределенными секциями.
Основной геморрой был с фасадами и с orm.
iborzenkov
0
Я не говорю что «Все что не Симфони — плохо», я говорю что плохо брать компоненты мощного фреймворка и прикручивать их как в ларавеле. Разумеется я буду сравнивать ларавел с симфони потому что половина его компонентов это обертки над компонентами симфони, причем такие что до сложного функционала не добраться. И критики было бы меньше, если бы просто ларавел взял компоненты симфони и нормально их использовал не создавая такие обертки.

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

Вот еще пачка минусов
1) Очень слабая ORM — это свалка — в одной только model находится сама модель, выборки коллекций, построитель запросов, менеджер коннекшенов, работа с событиями, сериализация.
Причем все это сделано так, что ломает автокомплит и вводит слишком много магии — всякие where(), scope, туда же еще прикрутили таймштамы и softDelete.
2) blade — это по сути смарти — постая замена тегов на php в файле, больше ничего нету, да, для начала 2000-х было нормально, сейчас уже есть нормальные шаблонизаторы
3) разработчик берет компоненты симфони и пишет для них свои обертки, причем только для самого базового использования — например роутер — только один вариант использования — через php в одном файле объявить сразу весь, причем под капотом используется симфоневый, который поддерживает разные форматы ресурсов, и достаточно мощный
4) Фасады — кривейший паттерн, ломает нафиг автокомплит и работать хоть как-то можно с костылями ide_helper — при этом хомячки кричат что это не синглетон и можно подменять — какое блин счастье, подменять можно, а все другие минусы забыли — по сути это очень криво реализованный контейнер, в котором нужно прописывать каждый объект отдельным фасадом.

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

Еще такая забавная вещь — в ларавеле по сути два типа модулей/компонентов либо своя кривая поделка (элоквент, конфиг, blade) либо прибитый гвоздями компонент симфони (или либа) обернутый в самый базовый вариант использования (роутер, реквест, консольные команды)
iborzenkov
–1
[facepalm.jpg]
Мы против изпользования всякого г только потому что это разрекламированная шняга.

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

Какие у него плюсы простите, из-за которых он вдруг стал таким замечательным?
iborzenkov
+1
Почти, только еще добавлю что не за новинками, а за разрекламированными вещами, причем бездумно, используя вешь потому что она популярна. Как бы ничего в новинке плохого нет, если нормальная штука, а вот если вокруг проекта поднялся хайп, то это повод на него обратить внимание и разобрать, может и норм, а не бросаться на нем в продакшен сразу, потому что может и г.
iborzenkov
+3
Ну все, началось.
Оверхед на компонентном фреймворке, на котором есть minimal edition? Или под оверхедом вы подразумеваете использование библиотек? Или то что для простой задачи не придумывают простой велосипед, если уже есть решение которое справляется и с простой и со сложной задачей?

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

Не нужно вам фанатеть по поводу ларавеля, раз уж не понимаете что это обычный хайп. Обычный средний фреймворк, со своими поделками и косяками. Какие у него плюсы простите, из-за которых он вдруг стал резко подходить большинству разработчиков?
iborzenkov
–7
Ой, не буду холиварить, а то прибегут хомячки Тейлора, ну нафиг.
В двух словах из хорошего фреймворка выкинули сложные для изучения компоненты и заменили кривыми поделками, а потом еще развели хайпа.
iborzenkov
+5
Круто блин, хайп вокруг ноды и хайп вокруг ларавела встретились.
Ну да, хипстеры, которым нравится и то и то будут довольны, а больше и не надо ничего.
iborzenkov
+4
Ну так в папочке (docker || ansible || provision ||… ) оно обычно и лежит.
iborzenkov
+2
Вот именно — напрячься и сделать по хорошему, запушив после этого в репу то что нужно.
В частности и настройки IDE если 90% пользуются ей. Там можно не только стиль кода, там например могут быть уже преднастроенные параметры запуска тестов локально, vagrant или docker, деплой на тестовые сервера. Разумеется это никак не заменяет скажем билд сервера с запуском тестов, анализаторов и форматеров кода, взаимодействие с которыми кстати тоже можно в эти конфиги сохранить.
iborzenkov
+2
Вообще-то проекта. Из локального там только workspace.xml и tasks.xml.
И если его правильно (https://www.gitignore.io/api/phpstorm) игнорить, то можно таскать настройки стилей кода и прочие вкусности в проекте, а не настраивать все время.
Общие настройки хранятся в ~/.PhpStorm/config по дефолту.
iborzenkov
0
Злые вы, у него хотя бы классы есть :)
Хоть какая-то структура, логика, фронт-контроллер базовый (index.php) и роутинг уровня кодеигнайтера
Хоть заюзал вполне адекватную либу для базы данных, хоть и написал сначало свой велосипед.
Ну хоть уровень выше чем уроки Попова :) Мелкие студии в начале 2000-х и хуже творили.
iborzenkov
+12
Открытие сделали блин.
Проверка на подмену DNS запросов уже есть в https://github.com/ValdikSS/blockcheck
iborzenkov
0
не показывает процесс, а это как раз чаще всего и нужно