Пилот в столе выглядит удобно, но это значит, что все провода от него будут лежать у вас на столе и мешаться.
Пилот на 2-3 розетки это прям впритык и скорей всего не хватит на все что нужно.
USB в пилоте выглядит удобно, но как мы знаем, разъем USB при активном использовании очень быстро приходит в негодность и заменить его если он встроен в стол сильно затруднительно. На практике у нас несколько раз сгорали компьютеров из-за поломанных USB на морде системника.
USB в торце стола выглядит интересно, но выламываются такие просто на раз. Проверено.
Беспроводная зарядка действительно хорошее решение, но она сильно привязывает нас к позиционированию телефона на столе и соответственно позиционированию нас относительно стола. Сесть чуть правей, чуть левей или чуть под углом уже нельзя.
Подогрев кружки встроенный в стол также сильно ограничивает наши возможности позиционирования относительно стола.
Колонки встроенные в стол очень плохая идея. Качество звука скорей всего чуть лучше чем у динамиков в ноутбуке. В офисе в колонках особо ничего не послушаешь, а дома можно и нормальные колонки поставить. Единственный кейс который я себе представляю это Skype конференции для больших боссов. И бумаги ни какие на стол не положишь, потому, что перекроешь колонки. Колонки открытые, направлены вверх и чуть утоплены в поверхность стола, это значит, что там будет собираться куча пыли и весь мусор и крошки который вы будете стряхивать со стола окажется в этих колонках, а выскребать их от туда будет сильно затруднительно.
Столы типа крыло выглядят красиво и необычно, но с практической точки зрения не удобны. У нас на работу подобные стоят и все плюются. Стол широкий, больше чем нужно и на края ничего не положишь. При этом стол не глубокий и ноги особо не вытянешь и разместить клавиатуру так, что бы локти лежали на столе также затруднительно. Из-за неправильной формы возникают проблемы с тем, что бы впихнуть их в ограниченное прямоугольное пространство. Классические прямоугольные столы в разы лучше впихиваются.
Регулировка высоты штука классная. Можно идеально подогнать высоту стола под свой стул и свои удобства. Но как сказали выше, это требуется сделать один раз и все. После этого эта функция потребуется только если вы решите сменить стул на другой с другой высотой, причем еще стулья должны быть не регулируемыми по высоте, иначе проще стул поднять чем стол.
На мой взгляд, лучше простой ровный стол, без излишеств и с одной дыркой по центру стола в которую уходят все провода и нормальный органайзер для проводов под столом. А если хочется отдельную зарядку для телефона на столе, то на мой взгляд лучшим решением будет эта настольная лампа от IKEA.
Меня больше интересует вопрос OpenSource.
Часто, в процессе работы на основной работе, на основным проектом, над задачей в рамках основного проекта рождаются самостоятельные и независимые утилиты/компоненты/модули/тулзы которые не связаны на прямую с задачей и проектом. Часто такие независимые единицы выкладывают в OpenSource от имени автора разработчика. Половина проектов на GitHub таки.
Вот я и думаю, имеет ли работодатель права на такие проекты? На сколько я понял из стать, в большинстве случаев не имеет, но бывают исключительный кейсы. А где грань тогда?
Даже для того, чтобы просто посылать логи в Sentry тоже требуется небольшая разработка.
У нас Symfony и для нее есть готовый бандл, так что у нас с подключение Sentry вообще никаких проблем. Так же есть интеграция GitLab <=> Sentry. И нам вполне хватает стектрейса собранного Sentry для идентификации и исправления проблемы. Но в вашем случае конечно все гораздо сложнее с учетом вашей архитектуры и вам нужно значительно больше данных чем может собрать Sentry. Тут я не спорю.
Я лишь хочу сказать, что Sentry очень хорошо подходит для не очень больших проектов. Так сказать, инструмент для старта.
То есть вас смущает, то что проекте с открытым исходным кодом в коммите ссылаются на тикет который нельзя почитать? Как и сказал ilammy, это не проблема git или GitHub в частности.
Какую альтернативу вы предложите в контексте обсуждаемой стати при использовании внутренней JIRA? Описывать в каждом коммите полный текст тикета? И даже если тикет на десятку, сотню или даже тысячу коммитов? А как на счет обсуждений тикета? Их тоже дублировать в сообщении к коммитам?
Мы для отслеживания ошибок используем Sentry. При первом подключении было много ошибок и влетало это в копеечку, но все ошибки поправили за пару месяцев и мы переключились на бесплатный плат. Сейчас редко выходим за лимиты бесплатного плана. 2 года в бою, полет нормальный.
Конфиденциальные данные мы в Sentry не отправляем, поэтому с этим проблем нет. Но разработать свой аналог это конечно круто. Вы молодцы.
А вы смотрели этот репозиторий? Это проект к php-fig имеет довольно посредственное отношение. Автор этого проекта по сути один человек dereuromark и он меняет многие устоявшиеся нормы, в частности:
Code MUST use 1 tab for indenting, not spaces. Spaces are for alignment and separation of words/text, only tabs are by definition valid indentation characters.
Я не думаю, что стоит рассматривать этот проект всерьез или у вас есть другая информация?
Я безусловно согласен с тем, что использование strict mode по умолчанию является хорошей практикой, но в данном случае и без него код будет работать корректно.
И вы забыли еще об одной детали:
If the requested component doesn't exist within the given URL, NULL will be returned.
В изначальном коде не выполнялась проверка на корректность URL и я полагаю, что валидация URL была сделана где-то ранее. То есть, задача этой строчки кода только проверить допустимый домен в URL, а не проверять корректность URL.
И здесь неважен strict mode и false который может вернуть функция parse_url(). В этом примере in_array()всегда будет возвращать false для таких случаев.
Довольно сомнительные решения.
На мой взгляд, лучше простой ровный стол, без излишеств и с одной дыркой по центру стола в которую уходят все провода и нормальный органайзер для проводов под столом. А если хочется отдельную зарядку для телефона на столе, то на мой взгляд лучшим решением будет эта настольная лампа от IKEA.
боже упаси. лишняя подсветка добавляет нагрузку на глаза которые и так вечно устают
или можно взять что-то по проще
https://github.com/gpslab/payload
Меня больше интересует вопрос OpenSource.
Часто, в процессе работы на основной работе, на основным проектом, над задачей в рамках основного проекта рождаются самостоятельные и независимые утилиты/компоненты/модули/тулзы которые не связаны на прямую с задачей и проектом. Часто такие независимые единицы выкладывают в OpenSource от имени автора разработчика. Половина проектов на GitHub таки.
Вот я и думаю, имеет ли работодатель права на такие проекты? На сколько я понял из стать, в большинстве случаев не имеет, но бывают исключительный кейсы. А где грань тогда?
Тогда уж должно быть так:
Хотя из кода совершенно не понятно, что это за магическое условие.
Symfony OptionsResolver
удалено
А через симлинк не работает?
У нас Symfony и для нее есть готовый бандл, так что у нас с подключение Sentry вообще никаких проблем. Так же есть интеграция GitLab <=> Sentry. И нам вполне хватает стектрейса собранного Sentry для идентификации и исправления проблемы. Но в вашем случае конечно все гораздо сложнее с учетом вашей архитектуры и вам нужно значительно больше данных чем может собрать Sentry. Тут я не спорю.
Я лишь хочу сказать, что Sentry очень хорошо подходит для не очень больших проектов. Так сказать, инструмент для старта.
То есть вас смущает, то что проекте с открытым исходным кодом в коммите ссылаются на тикет который нельзя почитать? Как и сказал ilammy, это не проблема git или GitHub в частности.
Какую альтернативу вы предложите в контексте обсуждаемой стати при использовании внутренней JIRA? Описывать в каждом коммите полный текст тикета? И даже если тикет на десятку, сотню или даже тысячу коммитов? А как на счет обсуждений тикета? Их тоже дублировать в сообщении к коммитам?
Мы для отслеживания ошибок используем Sentry. При первом подключении было много ошибок и влетало это в копеечку, но все ошибки поправили за пару месяцев и мы переключились на бесплатный плат. Сейчас редко выходим за лимиты бесплатного плана. 2 года в бою, полет нормальный.
Конфиденциальные данные мы в Sentry не отправляем, поэтому с этим проблем нет. Но разработать свой аналог это конечно круто. Вы молодцы.
Проблема известная и довольно старая. Тоже от неё страдаем. https://github.com/docker/for-win/issues/188
WSL 2 уже зарелизили, но мне ещё не довелось опробовать. https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/
А вы смотрели этот репозиторий? Это проект к php-fig имеет довольно посредственное отношение. Автор этого проекта по сути один человек dereuromark и он меняет многие устоявшиеся нормы, в частности:
Я не думаю, что стоит рассматривать этот проект всерьез или у вас есть другая информация?
А в чем проблема импортировать тикеты из GitHub в GitLab с сохранением номеров тикетов? Посмотрите на туже Doctrine.
Я безусловно согласен с тем, что использование strict mode по умолчанию является хорошей практикой, но в данном случае и без него код будет работать корректно.
И вы забыли еще об одной детали:
В изначальном коде не выполнялась проверка на корректность URL и я полагаю, что валидация URL была сделана где-то ранее. То есть, задача этой строчки кода только проверить допустимый домен в URL, а не проверять корректность URL.
И здесь неважен strict mode и false который может вернуть функция
parse_url(). В этом примереin_array()всегда будет возвращать false для таких случаев.В PHP это делается так
Точка без звёздочки заменяет только один символ. Как сказали выше, добавление
^$решит проблему.До недавнего времени, он был по умолчанию включён в php-cs-fixer и Style CI. Сейчас уже исправились.
Есть лайфхак Yoda conditions. Он помогает избежать ошибок в операциях сравнения, хотя мне такой стиль записи условий не нравится.