Search
Write a publication
Pull to refresh
2
0.1
Сергей @Chelyuk

User

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

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

Ну Selenium — такой Selenium. Написать тесты для конкретного браузера и для разных — это такие разные вещи, с багами переключения между окнами их открытием и закрытием остается либо смириться либо жить на старых версиях с известными багами как driver так и браузера. И никто не отменял что фикс бага в driver заставляет делать дополнительные фиксы в браузере, а значит и ждать новой версии.
А что касается синхронизации версий, рекомендую использовать — https://github.com/bonigarcia/webdrivermanager. Но да, там тоже бывают баги. Чем больше чужого кода в своих проектах тем больше чужих багов и надо почитывать чужие баг-трекеры, release notes и т.д.

А как же иврит? И прочие безгласные языки? Пишем только согланые, остальное додумывается, пунктуация тоже по желанию. Есть немного восточных тонкостей с родами в множественном числе.
Спасибо за качественную статью.
Самое время воплощать емкую батарейку и переходить на рейл-ганы. Как по мне уже выжали из порохового оружия все что можно, нужно менять концепцию.
А так да по вопросу призвыников в армиях, ак они всегда хотят отстрелять боезапас и свалить в тыл за сменой. Реально на передовой целиться и стрелять будут только те кто пошел туда сознательно — гвардия, наемники. Один знакомыйвообще рассказывал практи израильских отрядов при бояв в городе — открывается дверь внутрь бросается УЗИ, в силу отсутствия предохранителей начинает стрелять при небольшом ударе. Что в ствою очередь заставляет его вращаться вокруг собственной оси. Вот как он отстреляет боезапас, врываются внутрь и добивают кто остался.
Вообще противно, что люби до сих пор занимаются такими глупостями как убивать себеподобных. Лучше бы в спортивных соревнованиях мерялись или рубились человекоподобными или прочими роботами.
На мой взгляд, большей проблемой чем бургеры является излишняя либеральность и толерантность. Темнокожишь нелья называть темнокожими, толстых толстыми. Скорее это отразилось на мастабах проблемы, а любовь к бургерам скорее индивидуальна и в среднем по странам не сильно отличается. Просто у нас есть остатки культа «красивого» мускулистого тела или просто здорового. А вот в штатах — это не политкорректно. В славянских странах любовь к блинам тоже заметна и непонятно на сколько бургеры страшнее.

Думаю возможно. Samsung в Британии работает по схеме — платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода, в обмен на старый. Т.е. от схемы с разовой оплатой по сути перешли на подписку. Интел тоже мог так сделать, мол вот вам устройства но мы знаем о проблеме поэтому в следующем поколении исправим и продадим в обмен на старые за пол или треть цены. Лояльность потребителей дороже стоит.

Это все классно, но я так и не понимаю чего хотят вендоры дальше. Кржанич, явно стреманулся и слил свои акции Microsoft, Intel зная об уязвимости решила выпустить поколение процессоров в которых по прежнему сохранена уязвимость, без компании с отзывом. Т.е. алчность победила, здравый смысл, я правда так не понимаю кто будет покупать их новые процессоры, но наверное от безысходности будут.
Я полагал, что все таки замена CPU должна стать основным решением а все эти заплатки должны только выиграть время для реализации главного плана. Но судя по действиям основных виновников не видно никаких намеков на решение основной проблемы — на что менять текущие CPU?
По-моему им следует доработать тот «плот-банан». Одного из парней каждой волной отбивало от него. Неплохо бы сделать за что держаться. А так скорее похоже на proof of concept, чем на реальный кейс.
В то время как на самом деле «диван» с турецкого — «собрание». «Сарай» оттуда же «Дворец», а многие любители блеснуть знанием английского в Турции, наткнуться на суровое непонимание слова «tea» и такого привычного для нас «чай»(cai).
Еще бы добавил, веселый польский «sklep» — «магазин».

Мне вот тоже очень интересно. ИМХО вопрос больше к оригиналу, команда архитекторов в разработке ПО выглядит для меня несколько странно. Может где-то такое и встречается, но ставить несколько человек в 1 проект архитекторами еще и не дай Бог на пересекающиеся задачи, как по мне не совсем адекватно. Архитектор в разработке он почти как Архитектор в фильме "Матрица", его по канонам английского можно употреблять только с определенным артиклем the. А вот если команда инженеров — то тут все ОК.

Сколько людей — столько и мнений. Мне правда казалось что вопросы L2TP в userspace и нехватка устройств на 5ГГц диапазон уже несколько устарели.

Никогда не понимал за что ругают популярные системы/продукты? Мир не идеален и в нем нет ничего идеального, все может только стремиться. Пока Unix/Linux имеет столь огромое сообщество это доказывает, что дохрена людей считают ее лучшим выбором из существующих. Кто считает таковой Windows, кто-то MacOS. Люди сделали свой выбор в пользу той или иной системы по совокупности качеств и характеристик. Не нравиться конкретно Вам, ну не используйте. Вклад Unix и ее производных в развитие технологий неоспорим, если бы не она. Сейчас был бы совсем другой мир. Не все решения в ней идеальны, но если их перенимают другие системы это доказывает их целесообразность.

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

  1. Понятно, что в идельном мире, у одного человека 1 проект. В реалиях, если компания не исчисляет сотрудников тысячами этого очень сложно добиться и придется совмещать. Но даже в реальной ситуации можно выкручиваться и я предполагаю что желательно если и разделять человека на проекты, то хотя бы делить группы проектов по методологиям. Будет ли выигрышь, если людей распределять, не между проектом 1-Scrum и проектом 2-Waterfall, а между проектом 1-Scrum и проектом 2-Scrum. Или если у человека будет 2 проекта уже не столь принципиально одна в них методика или разная?


  2. Кейс примерно такой:
    Проектальная компания, порядка 40-45 человек из них около 25 разработчиков и 5 тестировщиков. Остальные менеджмент, компания территориально разделена. Менеджмент — одна локация, разработчики и тестировщики — другая локация. Локации — 1 часовой пояс, но 3000 км.
    Проекты есть разные, небольшая нагрузка по саппорту, 2-3 основных длительных проекта в которых задействованы от 10 человек(разработчиков и тестировщиков) компании и проекта 3-4 где потребность в людях возникает периодически(3-4 человека), так сказать фоновые проекты.
    Девелоперы делятся между 4мя лидами, тестировщики закреплены за 1м лидом. Основные проекты ведуться 1 по сценарию приближенному к WaterFall, 2 других на субподряде у основного заказчика декларируется Scrum.
    Вот пытаюсь во всем этом нащупать балланс, учитывая что раньше практически все проекты шли по WaterFall c некоторыми изменениями. Либо, действительно упразднить такое явление как Team Lead тестировщиков и двигаться в сторону перераспределения ролей по Scrum сценарию(PO, SM ...). Либо искать еще какие-то варианты перераспределения, например как предложили выше, оставить тимлидов разработчиков и перевести тимлида тестировщиков в discipline.
    Вопрос вызван тем что работь на субподряде по жестким методикам стало крайне тяжело, когда есть зависимотсти своего кода от кода и сроков внешней команды заказчика,

Подскажите пару рекомендаций:
1) Реально ли использовать 1го сотрудника в проектах с разными методологиями(Scrum, support, Waterfall) или лучше стараться максимально разделять по проектам исходя из используемых методологий?
2) Как организационно в небольшой компании совмещать методологии? Например, разработчики и тестировщики разделены тим-лидами, что хорошо в случае WaterFall или CanBan. Agile и Scrum не очень разделяют такие взгляды, для них характерно другая расстановка ролей и 2 тим-лида в одну команду не очень хорошо укладываются, потому как TL должен взять на себя роль Product Ownera(PO), а 2 PO — это как 2 хозяйки на одной кухне.
Небольшая компания, где менеджеры не хотят набирать на каждую роль человека и приходится балансировать изображая человек-оркестр.

Если я правильно помню, то Scrum хоть и не равно Agile, но ноги у него растут из Agile, в котором четко прописано, что рекомендованный размер команды 6-8 человек. Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент. Если есть потребность в столь больших командах оправданы внедрения элементов WaterFall и требуется тратить время на бюрократию с документацией, иначе очень много проблем от "испорченного телефона".
Изменения в ТЗ вносится на 1 спринт, в течении спринта менять моветон. Длительность спринта -вопрос философский, обычно от 1ой недели до 1го месяца.

Information

Rating
4,090-th
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity