Ничего не имею против машин и автомобилей. Но если человек вместо этого в нормальном разговоре про новое и интересное называет его "квадрациклом с четырехтактным двигателем внутреннего сгорания", но сразу задумываешься, что кто-то пропускал в школе уроки литературы.
Специфические юридические обороты, на мой взгляд, выглядят более чем странно что в нормальной человеческой речи, что в техническом тексте.
В университете на юридическом факультете профессор спрашивает студента:
- Если вы хотите угостить кого-то апельсином, как вы это сделаете?
- Я скажу "Пожалуйста, угощайтесь!", - ответил студент.
- Нет-нет! - закричал профессор. - Думайте как юрист!
- Хорошо, - ответил студент. - Я скажу: "Настоящим я передаю вам все
принадлежащие мне права, требования, преимущества и другие интересы на собственность, именуемую апельсин, совместно со всей его кожурой, мякотью, соком и семечками, с правом выжимать, разрезать, замораживать и иначе употреблять, используя для этого любого рода приспособления, как существующие в настоящее время, так и изобретенные позднее, или без использования упомянутых приспособлений, а также передавать ранее именованную собственность третьим лицам с кожурой, мякотью, соком и семечками или без оных..."
Искренне поздравляю автора перевода с гениальной находкой: перевести "third-party developer" как "разработчиков третьей стороны". Жаль, не раскрыта тема местоположения стороны, которую они разрабатывают. А равно и первых двух сторон.
IMHO, "usually" здесь написано исключительно потому, что чисто теоретически такой ассемблер можно написать. Но я за 20 лет с такими не сталкивался ни разу.
Вы можете привести пример лично Вам известного ассемблера, который поступает вопреки этому правилу?
Что до обсуждаемого случая это именно испорченный телефон. Некто прочел вполне разумную статью о том, что бездумное применение Ajax повышает нагрузку на сервер. При этом он не понимал ни что такое Ajax, ни что такое Java, ни что такое "нагрузка". И всю эту "кашу с тараканами" вывалил на еще менее информированного приятеля. :)
Немножко не так: им нужно честно предлагать почасовую оплату. "Любой каприз за ваши деньги". Обычно, правда, не соглашаются. Но сами и добровольно. :) Никто никого не выгонял. :)
Абсолютно справедливо. "Как замечательно, что среди Ваших друзей есть люди с такими хорошими техническими знаниями. Я уверен, что передача контракта человеку, чьему мнению Вы безусловно доверяете, будет правильным решением. Кстати, за вполне разумные деньги мы выполняет доработку незаконченных проектов; вот Вам моя визитка."
Если отвлечься от нестыковок в точке зрения "хорошего друга", то я хотел бы узнать: а каким хитрым Дао вы владеете, если научились использовать Ajax НЕ создавая дополнительной нагрузки на сервер? У вас асинхронные запросы, в честь которых появилась первая буква A в аббревиатуре Ajax, посылаются на на сервер? А куда?
Так как это первый проект на Битриксе, то очень сложно предсказывать, какая задача займёт сколько времени (обучение зачастую идёт в процессе разработки). Более того, квалификация разработчиков различается настолько, что время выполнения подзадачи весьма чувствительно к исполнителю. То есть о времени выполнения задачи можно строить только приближённые предположения.
Мне кажется, что в таких условиях вам нужно не софт искать, а изменить организацию разработки. Посмотрите в сторону Agile методов управления проектами. В вашем случае как раз разумно позволить разработчикам самим оценивать объем работы и самим выбирать, кто за что возьмется.
Также очень хотелось бы, чтобы у исполнителей висела в трее лёгенькая утилитка, в которую можно было бы импортнуть список задач из головной программы. Исполнитель бы удобно отмечал проделанные задачи и время их выполнения, суммарное, складывающееся из событий
Опять же: здесь не софт нужен. Здесь нужно налаживать общение внутри команды. BTW, я вообще не очень представляю, зачем вам нужен протокол выполнения работ с деталировкой до получаса и как вы собираетесь его использовать.
Вести протокол СВОЕЙ загрузки для последующего ЛИЧНОГО анализа штука полезная. Например, при использовании в рамках PSP. Позволяет серьезно повысить эффективность работы. Но требуется бОльшая точность (минуты) и последующий анализ лично у меня занимал от сорок минут до часа на дневной протокол. Анализировать так работу подчиненных опускаться до микроменеджмента.
Не следует путать обсуждание стартапа и обсуждение его основной идеи. Например, я не вижу чем обсуждение проблем бэтатестирования может навредить стартапу.
Дефолтная (но не единственная!) тема первой встречи - сам ОпенКофе.
Вот это метавстречи больше всего настораживает. Если у встречающихся нет потребности посвятить первую же встречу обсуждению своих/чужих стартапов, то зачем вообще собираться?
startup
1: the act of setting in operation; "repeated shutdowns and startups are expensive"
2: the act of starting a new operation or practice; "he opposed the inauguration of fluoridation"; "the startup of the new factory was delayed by strikes" [syn: inauguration]
На счет актуальных потребностей и получения прибыли это Вас кто-то обманул.
Похоже на фейк еще и из-за фразы про то, что впервые создана клавиатура, "каждая клавиша которой является программируемой". В действительности такие клавиатуры выпускаются давно (стоят, правда, дурных денег) и вряд ли в Логитеч о них не слышали.
Вы можете привести пример лично Вам известного ассемблера, который поступает вопреки этому правилу?
Немножко не так: им нужно честно предлагать почасовую оплату. "Любой каприз за ваши деньги". Обычно, правда, не соглашаются. Но сами и добровольно. :) Никто никого не выгонял. :)
Мне кажется, что в таких условиях вам нужно не софт искать, а изменить организацию разработки. Посмотрите в сторону Agile методов управления проектами. В вашем случае как раз разумно позволить разработчикам самим оценивать объем работы и самим выбирать, кто за что возьмется.
Опять же: здесь не софт нужен. Здесь нужно налаживать общение внутри команды. BTW, я вообще не очень представляю, зачем вам нужен протокол выполнения работ с деталировкой до получаса и как вы собираетесь его использовать.
Вести протокол СВОЕЙ загрузки для последующего ЛИЧНОГО анализа штука полезная. Например, при использовании в рамках PSP. Позволяет серьезно повысить эффективность работы. Но требуется бОльшая точность (минуты) и последующий анализ лично у меня занимал от сорок минут до часа на дневной протокол. Анализировать так работу подчиненных опускаться до микроменеджмента.
Супергениальный стартап.
На счет актуальных потребностей и получения прибыли это Вас кто-то обманул.