какие-то еще операции, кроме git reset влияют на ORIG_HEAD и что произойдет с веткой коммитов на который указывал ORIG_HEAD после того, как он изменится?
описание PrEn разбито на последовательные этапы и поэтому производит впечатление еще и методики разработки. но выполнение таких шагов ещё не дает гарантий для получения ожидаемого результата.
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
мне кажется, что корни GrDe можно поискать еще и в процессах разработки.
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
Мы решили не ломать стандартную сортировку писем в почте, когда первое письмо — снизу, последующие — сверху, и поддержать её в тредах.. Кроме того, до нас это отлично сделал Apple Mail, так что здесь было на кого равняться.
можно-ли настроить интерфейс так, чтобы письма внутри треда сортировались в прямом хронологическом порядке, а не задом-наперед? (сами треды пусть сортируются как сейчас — в обратном порядке, по дате последнего сообщения).
мне кажется, что в отличие от того же твиттера, где отдельные сообщения между собой ни как не связаны, письма в треде связаны друг с другом самым непосредственным образом, и поэтому их удобнее читать подряд, линейно — т.е. строго сверху вниз. не знаю о чем думали разработчики эпл, но заставлять прыгать снизу вверх, прочитав предыдущее письмо, чтобы найти следующее за ним, это не логично и не гуманно. '-)
мне кажется, что применительно к IT'шникам пирамидку надо переворачивать — для них «познавательные потребности» являются базовыми, а физиологические (которые «голод, жажда, половое влечение и другие») — дело десятое. :)
волнует не сколько конкрентая ситуация, а вообще данный способ реализации dependency injection, внутри django. ведь разработчики примут это за best practices и начнут подражать направо и налево. в пределе — все ссылки внутри ForeignKey заменяются константами из settings — что дикий ужаснах.
кстати, ни что не мешает одной СУБД выставлять разные интерфейсы наружу, и давать, тем самым, возможность приложению использовать для работы с данными наиболее подходящие модели, в зависимости от решаемой задачи. например: * *
раньше говорили о разделении слоев представления данных в СУБД — физического и логического. в этом смысле SQL является не архитектурой БД, а интерфейсом слоя логического преставления данных, который позволяет приложению работать с данными в терминах реляционной модели.
Смысл таков, что в NoSQL базах в отличие от реляционных структура данных не регламентирована
мне кажется, что рассуждать в ключе, дескать NoSQL базы снимают ограничения реляционных — занятие, в достаточной степени, бестолковое. это все равно, что искать преимущества какого-нибудь типа, типа dict, над каким-нибудь типом, типа tuple. модели всякие нужны, модели всякие важны. они предоставляют различные интерфейсы, каждый со своими особенностями.
идея реляционной модели состоит в представлении базы данных как коллекции логических высказываний (что характерно, где в каждый конкретный момент времени удовлетворены абсолютно все из них).т.е., по сути, это навороченный логический аппарат для оперирования высказываниями, касательно фактов предметной области. самостоятельно кодить такое внутри приложения — занятие достойное лишь Чака Норриса. поэтому жить реляционные будут еще очень долго и счастливо. просто нужно понимать, что структуры данных, c которыми эти базы предлагают работать приложению, относятся не приложению вовсе, а к самой модели базы данных и являются частью её интерфейса. отсюда все заморочки, если база нужна приложению не для извлечения логических утверждений, а для чего-то иного.
для чего-то иного, нужно выбирать более подходящие модели представления данных. нужно, и даже — можно. сейчас мне кажется, что эта простая мысль стоит за всей шумихой вокруг NoSQL (по сути, такой выбор программисты делаю по сто раз на дню, пока не начинают относится к вопросу как задаче хранения данных :))
Ознакомление работника с различными документами также может происходить через интернет.
ознакомление под роспись?
представляю, инструктаж по технике безопасности или вручение выговора — «получи и распишись!» (электронно)
кстати, интересно, как будет выглядеть электронный штамп в трудовой книжке (и будет-ли вообще как у нормальных оффлайновых сотрудников)?
возможность использования усиленной квалифицированной электронной подписи при составлении в электронном виде трудового договора, где необходимы подписи сторон.
похоже, гос-во таким образом расширяет рынок ЭЦП.
ЭЦП, с самого начала, появилась как платная штука (заметно платная, по сравнению со стоимостью ручки и бумаги :)). для физиков дешевле, для юриков — в разы дороже. принцип ценообразования не понятен, но за короткое время придумали уже массу разновидностей, на всякие случаи жизни. куда ни плюнь, нужна особая подпись. срок годности — ограничен. наверняка, появится в продаже эцп «для составления трудовых договоров».
Функциональные тесты полностью определяют (по крайней мере должны) работоспособность продукта. И прежде всего нужны заказчику/руководителю разработки. Юнит тестирование прежде всего нужно самим разработчикам, для быстрого нахождения ошибок или проверки последствий рефакторинга. Поэтому приоритет должен стоять таким образом:
Функциональные тесты — обязательно
Юнит-тесты — желательно, но зависит от настроения разработчиков
заказчку нужны сроки, руководителю — бабло, а разработчику — писать код. поэтому в чистом виде, любые тесты зависят от настроения, т.к. напрямую не уперлись никому. их использование граничит с вопросами экологии или культуры. :)
мне кажется, что ваша приоритезация, вероятно, отражает текущую фазу разработки. когда, в моменте, доминирует проектирование «сверху-вниз», то появляются acceptance-тесты и тесты, порождаемые по дедукции в tdd, как на картинке. когда синтезируется решение «снизу-вверх» — юнит и интеграционные.
если рассматривать инструменты (* тесты, автоматизацию, кодогенерацию), методики разработки (*DD, стратегии тестирования, рефакторинг) и цели (фиксацию требований, снижение доли ручного труда, выявление регрессий) в отдельности, то появляется больше степеней свободы.
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
можно-ли настроить интерфейс так, чтобы письма внутри треда сортировались в прямом хронологическом порядке, а не задом-наперед? (сами треды пусть сортируются как сейчас — в обратном порядке, по дате последнего сообщения).
мне кажется, что в отличие от того же твиттера, где отдельные сообщения между собой ни как не связаны, письма в треде связаны друг с другом самым непосредственным образом, и поэтому их удобнее читать подряд, линейно — т.е. строго сверху вниз. не знаю о чем думали разработчики эпл, но заставлять прыгать снизу вверх, прочитав предыдущее письмо, чтобы найти следующее за ним, это не логично и не гуманно. '-)
мне становится как-то не по себе, если этот паттерн войдет в моду. :/
мне кажется, что рассуждать в ключе, дескать NoSQL базы снимают ограничения реляционных — занятие, в достаточной степени, бестолковое. это все равно, что искать преимущества какого-нибудь типа, типа dict, над каким-нибудь типом, типа tuple. модели всякие нужны, модели всякие важны. они предоставляют различные интерфейсы, каждый со своими особенностями.
идея реляционной модели состоит в представлении базы данных как коллекции логических высказываний (что характерно, где в каждый конкретный момент времени удовлетворены абсолютно все из них).т.е., по сути, это навороченный логический аппарат для оперирования высказываниями, касательно фактов предметной области. самостоятельно кодить такое внутри приложения — занятие достойное лишь Чака Норриса. поэтому жить реляционные будут еще очень долго и счастливо. просто нужно понимать, что структуры данных, c которыми эти базы предлагают работать приложению, относятся не приложению вовсе, а к самой модели базы данных и являются частью её интерфейса. отсюда все заморочки, если база нужна приложению не для извлечения логических утверждений, а для чего-то иного.
для чего-то иного, нужно выбирать более подходящие модели представления данных. нужно, и даже — можно. сейчас мне кажется, что эта простая мысль стоит за всей шумихой вокруг NoSQL (по сути, такой выбор программисты делаю по сто раз на дню, пока не начинают относится к вопросу как задаче хранения данных :))
представляю, инструктаж по технике безопасности или вручение выговора — «получи и распишись!» (электронно)
кстати, интересно, как будет выглядеть электронный штамп в трудовой книжке (и будет-ли вообще как у нормальных оффлайновых сотрудников)?
ЭЦП, с самого начала, появилась как платная штука (заметно платная, по сравнению со стоимостью ручки и бумаги :)). для физиков дешевле, для юриков — в разы дороже. принцип ценообразования не понятен, но за короткое время придумали уже массу разновидностей, на всякие случаи жизни. куда ни плюнь, нужна особая подпись. срок годности — ограничен. наверняка, появится в продаже эцп «для составления трудовых договоров».
офф: подскажите, как вы конвертировали разметку из markdown в хабра-html?
заказчку нужны сроки, руководителю — бабло, а разработчику — писать код. поэтому в чистом виде, любые тесты зависят от настроения, т.к. напрямую не уперлись никому. их использование граничит с вопросами экологии или культуры. :)
мне кажется, что ваша приоритезация, вероятно, отражает текущую фазу разработки. когда, в моменте, доминирует проектирование «сверху-вниз», то появляются acceptance-тесты и тесты, порождаемые по дедукции в tdd, как на картинке. когда синтезируется решение «снизу-вверх» — юнит и интеграционные.