А что делать с задачами стоящими, скажем 1000 рублей каждая, но которых, скажем 1000 в бэклоге? Обычно такие мелкие задачи составляют основной процент работы каждого программиста.
С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность. Ну не может начальник ДИТ и другой начальник решить насколько нужна какая-нибудь формочка или отчет. Они слишком высоко стоят в иерархии. Когда они пытаются на это отвлекаться, то либо не успевают, либо увязают в бюрократии.
Для эффективной разработки очень нужны горизонтальные связи с заказщиком (внутренним или внешним).
Ну если коротко, то да, я считаю что программист должен разбираться в той сфере в которой пытается действовать, иначе его эффективность сильно падает.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист. Задержки в этой цепочке слишком велики, а в наше время решают не технологии а скорость их внедрения. Да и экономия от увольнения двух лишних в цепочке людей будет существенной, даже с учетом более высокой стоимости квалифицированного человека и неизбежного дубляжа позиций в разных отделах.
Да черт возьми, иногда надо автоматизировать отчет, который нужен раз в год. Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать.
Я немного не о том. Тети в бухгалтерии не будут думать о целесообразности. Они просто вернутся к привычным и работающим инструметам (вплоть до калькуляторов), а фичи, добавляемые в продукт и одобреные десятком вицепризедентов, использоваться не будут. Т.е. при таком подходе мы наталкиваемся на типичную проблему, когда ДИТ делает на бумаге все очень круто, но на деле занимается совершенно бесполезной работой. Подобный собатаж на мой взгляд самый большой головняк в больших компаниях. И единственное рабочее решение которое я знаю, это иметь своего человека среди целевой аудитории или отрправлять туда программистов на искупление.
Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
На самом деле причина такой колосальной разницы между «настоящими» DNS и dnsmaq в том, что большие DNS сделаны для того, чтобы обслуживать крупные авторитативные DNS в интернете. Поэтому они сразу тащат все в память, предполагая, что производительность важнее и хостер с 400к доменов уж может себе позволить 5G памяти.
А dnsmasq сделан именно как прокладка между локальным компом или максимум локальной сеткой и большим миром, поэтому логика его работы совсем другая. Если не пытаться разом обратится ко все 600К доменам, то и память он не должен так кушать.
Подозреваю, что это почти единственный способ заставить большие компании работать быстро.
К слову сказать в некоторых дистрибах Linux патчи в краеугольные проекты (openssl например) умудряются принять за несколько часов. Уж не знаю как они это делают. Может манагеров меньше, а технарей больше.
Вспоминается старый анекдот: «и вот теперь со всей этой… мы попытаемся взлететь».
У вас есть опыт эксплуатации этого скажем года два? Какой уровень доступности получили? Были ли за это время проблемы с железом? Что делали, если понимали, что мастер упал на долго и неизвестно все ли изменения приехали?
Я думаю имелось ввиду, что некоторые операции в git заведомо опасны и могут необратимо сломать локальный индекс. Это сделано не зря, поскольку для больших проектов (в первую очередь ядро Линукс) это необходимо, но для новчиков это минное поле: нашел инструкцию в интернете, ошибся, клонируйся заново. На StackOverflow это распространненый класс вопросов по git.
Странные люди. Уж на что я линуксойд, но лет пять назад предлагал руководству перенести почту на Exchange именно из-за этой фишки. С тех пор дедупликация вложений появилась в Dovecot а полная дедупликация тела письма (без заголовков) в DBMail, правда сырая.
Насколько я знаю одно из больших приемуществ именно Exchange в том, что у него есть дедупликация. Думаю, точнее надеюсь, в облаке это тоже реализовано. Т.е. pdf будет лежать только один раз.
Это только вершина айсберга. Скорее проблема в том, что нужно реально понимать что ты делаешь. Но с другой стороны админов держат не за бороду и свитер, а за другие заслуги.
Если коротко, то лучший путь работы со стронней CMS это, во-первых, разобраться в движке хотябы с точки зрения админа (куда пишет, откуда берет конфиги, как обновляется, как конектится к другим сервисам), и, во-вторых, построить CI для нужного софта, хотя бы на уровне дайджеста коммитов, который можно глазами посмотреть.
Тут мы опять получаем проблему с тем, что если в где-то в движке есть уязвимость, то он может написать свои .htaccess в те директории к которым есть доступ, а это уже путь к уязвимости описаной в посте.
К сожаленю нельзя ограничить .htaccess в другом .htaccess. Т.е. нельзя на шаред хостинге создать структуру в которой все .htaccess либо лежат в реадолни, либо не читаются апачем. Такое навернуть можно только если есть доступ к конфигу. И с этой точки зрения я очень позитивно смотрю на фреймворки, которые хранят временные и пользовательские файлы в базе данных. Такие движки и контейнизировать легко.
Я предпочитаю полностью запрещать запись в директории (кроме тех, что действительно нужны движку на запись) и полностью запрещаю htaccess файлы, перенося всю конфигурацию в конфиг файлы apache, доступные только руту. Кроме того пользователь под которым работает apache должен быть максимально бесправным, а все core расширения запрещены, кроме списка действительно нужного (в 2.4 с этим стало гораздо удобнее управляться).
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.
Это было в времена до 10g. Да даже в 9i это рекомедовалось делать только от безнадеги, посколько управлять этими разделами было сложновато. Этот подход считается устаревшим и не рекомендуется. У Оракл теперь есть специализированная система для хранения ASM (специальная файловая система + управляющий сервис). Приемущество ASM над RAW в том, что ASM «знает» что за данные у него лежат и может оптимизировать исходя из логи работы базы данных. Кроме того в ASM есть разные дополнительные возможности с точки зрения кластеризации, реплицирования и т.д.
Nokia, Blackberry и MS умудрились проспать смартфонную революцию, которую устроили новые игроки рынка (Apple и Google). При этом предпосылки такого взрыва были налицо. Я слабо представляю, что за революция должна произойти в десктопе, чтоб MS потеряли и этот рынок. Единственное что им реально неприятно, так это исчезновение самого десктопа: планшеты, смартфоны, умные телевизоры постепенно захватывают «не профессиональный» рынок.
Самое главное правило, которое я вынес из работы в этой сфере: интерфейс не должны проектировать программисты. Особенно бэкенд программисты (и здесь похоже тот самый случай). Их вообще надо изолировать от этой задачи и не давать права голоса.
Дело не в том, что руки у них не правильные, а в парадигме: они стремятся в интерфейс вынести внутренюю структуру приложения. Для них это естественно: они думаю моделями нормализованных таблиц, функциональных модулей и пространств имен.
Например телефон и почтовый адрес могут оказаться в разных концах CRM просто по той причине, что первый связан с модулем АТС, а второй нет. Или может быть принято решение, что основа нашего интерфейса таблица. Это решение основано не на коридорном тестировании, а на том, факте, что программист целый день смотрит на базу данных через свою IDE и просто привык к таблицам. Но никто конечно вам в этом не признается и будет отстаивать свою точку зрения до последнего.
Ещё один грешок, который водится за такими интерфейсами это не очень нужный, но крутой функционал, который очень хочется показать в интерфейсе. В продукте который я разрабатывал до недавнего времени была довольно крутая фишка: срок действия значения параметра. Т.е. на низком уроне параметр был не просто значением, а целой таблицей с расписанием переключения. Надо признать это было удобно в 10-15 местах. Например можно было изменить количество обработчиков для разных классов задач в разное время (ночью одно, днем, в бизнес часы, другое), установить срок действия показа банера с акцией (чтоб не забывать в разговоре с клиентом об этом). Но в остальных 10500 местах это просто было не нужно: человек который менял значение, ожидал, что вот прям сейчас оно и поменятся. Но беда в том, что как наверное вы уже догадались, интерфейс был в виде таблицы, спрятаной под универсальной формой показа значения. По моим подсчетам на исправление параметра у меня уходило до 9 кликов. Конечно в тех местах, где клиентов это задрало до безобразия таблицы на параметрах убрали, но в целом от этого не откзались и по сей день (насколько мне известно). Получилось, что, пусть и хороший, но относительно не востребованный функционал выпячивался в угоду эго того, кто это написал, и в ущерб зравому смыслу.
Эм. А зачем вообще подобный софт на сервере? Статической конфигурации для сервера более чем достаточно. Зачем держать некий демон в памяти если настройка сети с 99% вероятностью больше не будет менять после перезагрузки?
Тем не менее он упоминает об этом в одной из своих книг и более подробно расказывает в воспоминаниях для журнала Life (выпуск 30 октября 1950). Статья «Face To Face With Stalin».
All was instantly prepared. I noticed that the basins were not fed by separate hot and cold water taps and that the had no plugs. Hot and cold turned on at once through a single spout, mingled to exactly the temperature one desired. Moreover, one did not wash one's hands in the basins, but under the flowing current of the taps. In a modest way I have adopted this system at home. If there is no scarcity of water it is far the best.
Для эффективной разработки очень нужны горизонтальные связи с заказщиком (внутренним или внешним).
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист. Задержки в этой цепочке слишком велики, а в наше время решают не технологии а скорость их внедрения. Да и экономия от увольнения двух лишних в цепочке людей будет существенной, даже с учетом более высокой стоимости квалифицированного человека и неизбежного дубляжа позиций в разных отделах.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
А dnsmasq сделан именно как прокладка между локальным компом или максимум локальной сеткой и большим миром, поэтому логика его работы совсем другая. Если не пытаться разом обратится ко все 600К доменам, то и память он не должен так кушать.
К слову сказать в некоторых дистрибах Linux патчи в краеугольные проекты (openssl например) умудряются принять за несколько часов. Уж не знаю как они это делают. Может манагеров меньше, а технарей больше.
У вас есть опыт эксплуатации этого скажем года два? Какой уровень доступности получили? Были ли за это время проблемы с железом? Что делали, если понимали, что мастер упал на долго и неизвестно все ли изменения приехали?
Если коротко, то лучший путь работы со стронней CMS это, во-первых, разобраться в движке хотябы с точки зрения админа (куда пишет, откуда берет конфиги, как обновляется, как конектится к другим сервисам), и, во-вторых, построить CI для нужного софта, хотя бы на уровне дайджеста коммитов, который можно глазами посмотреть.
К сожаленю нельзя ограничить .htaccess в другом .htaccess. Т.е. нельзя на шаред хостинге создать структуру в которой все .htaccess либо лежат в реадолни, либо не читаются апачем. Такое навернуть можно только если есть доступ к конфигу. И с этой точки зрения я очень позитивно смотрю на фреймворки, которые хранят временные и пользовательские файлы в базе данных. Такие движки и контейнизировать легко.
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.
Дело не в том, что руки у них не правильные, а в парадигме: они стремятся в интерфейс вынести внутренюю структуру приложения. Для них это естественно: они думаю моделями нормализованных таблиц, функциональных модулей и пространств имен.
Например телефон и почтовый адрес могут оказаться в разных концах CRM просто по той причине, что первый связан с модулем АТС, а второй нет. Или может быть принято решение, что основа нашего интерфейса таблица. Это решение основано не на коридорном тестировании, а на том, факте, что программист целый день смотрит на базу данных через свою IDE и просто привык к таблицам. Но никто конечно вам в этом не признается и будет отстаивать свою точку зрения до последнего.
Ещё один грешок, который водится за такими интерфейсами это не очень нужный, но крутой функционал, который очень хочется показать в интерфейсе. В продукте который я разрабатывал до недавнего времени была довольно крутая фишка: срок действия значения параметра. Т.е. на низком уроне параметр был не просто значением, а целой таблицей с расписанием переключения. Надо признать это было удобно в 10-15 местах. Например можно было изменить количество обработчиков для разных классов задач в разное время (ночью одно, днем, в бизнес часы, другое), установить срок действия показа банера с акцией (чтоб не забывать в разговоре с клиентом об этом). Но в остальных 10500 местах это просто было не нужно: человек который менял значение, ожидал, что вот прям сейчас оно и поменятся. Но беда в том, что как наверное вы уже догадались, интерфейс был в виде таблицы, спрятаной под универсальной формой показа значения. По моим подсчетам на исправление параметра у меня уходило до 9 кликов. Конечно в тех местах, где клиентов это задрало до безобразия таблицы на параметрах убрали, но в целом от этого не откзались и по сей день (насколько мне известно). Получилось, что, пусть и хороший, но относительно не востребованный функционал выпячивался в угоду эго того, кто это написал, и в ущерб зравому смыслу.