В том-то и дело, что не в канаву. На лампах тоже можно цифровые вычислительные схемы делать, только у них предел оптимизации по стоимости и производительности глупо даже пытаться сравнивать с таковым для схем на основе полупроводников. Поэтому даже если в какой-то момент у них цена одинаковая, то это не значит ничего — одну из технологий через полгода оптимизируют, и она станет вдвое (условно) дешеве и эффективнее (обычное дело для начала периода начала распространения), а вторая так и останется практически на старом уровне и полезности, и цены.
Анализ изменения цен в любой валюте без анализа изменения стоимости самой валюты (не столько по отношению к другим валютам, сколько по отношению к другим товарам, потребительской корзине) имеет довольно мало смысла. Я понимаю, что в статье цены в долларах, а не в рублях, но со временем стоимость долларов тоже меняется.
Взять к примеру ваше первое сравнение цен на топовые смартфоны — рост цены на 20% за 9 лет. Если зайти на сайт www.usinflationcalculator.com, то там есть удобный калькулятор изменения цен в USD в связи с инфляцией. За 2007 — 2016 годы цены выросли примерно на 16 процентов, т. е. реально ваши 20% на самом деле — это всего 4%, что в масштабе одного десятилетия кажется не очень существенным. Надо сказать, что этот мой анализ длиной в пару строк тоже довольно поверхностен, но уже из этого кажется понятным, что просто сравнивать цены в долларах — странная затея.
Дальнейшие рассуждения про сравнение ЖК мониторов на заре распространения с сегодняшим днем, а потом еще и с ЭЛТ (вообще другой товар с точки зрения технологий) — тоже ни о чем. Далее вы упоминаете спрос, производство и кокуренцию, но не говорите ни слова о том, как они на самом деле формируют цену в данном случае. Потом идет анализ изменения цен на другие товары, но изменение цен в рублях, т. е. как это вообще связать со всеми предыдущими выкладкими? В общем, извините, но слабо.
На всякий случай, если из моего комментария выше это непонятно, то да, после номера тикета идет описание того, что именно было сделано (обычно умещается в одну строку).
А имена разработчиков dev1 и dev2, и одинаковый хэш коммитов вас не смущает? Это просто пример, не буду же я рельные комменты к коммитам здесь выкладывать? Тем не менее, структура дерева коммитов именно такая.
Мы уже давно (года три назад, после пары лет использования git flow) перешли на нечто подобное. После того как закончил работать над фичей: git checkout develop
git merge --squash feature/...
git commit -am '#issue comment'
git push origin develop
git branch -D feature/...
git push origin :feature/...
Тут даже невооруженным взглядом видно, что происходило в проекте: кто, что и когда сделал, что и когда пошло в релиз.
Зачем нужны промежужточный коммиты в фиче бранче, вообще не понятно. За все три года работы по такой модели я ни от одного из коллег не слышал, что ему нужно было знать, что было в промежуточных коммитах.
у админов, вероятно (и вы это подтверждаете), есть свои причины разрешать/запрещать хром и лису. это в общем-то не вопрос. но кажется, что таких десктопов в общей массе все-таки мало, и они никак никак не могу обеспечить IE долю в 41%, как это указано в статье
я что-то никак не пойму, откуда у них такая статистика. мне казалось, что осел сдох еще несколько лет назад, и только особые приверженцы и отдельные неудачники, которым админы на работе не разрешают поставить другой браузер, продолжают насиловать труп. вот первые три результата из гугла по запросу «browser statistics»: http://www.w3schools.com/browsers/browsers_stats.asp: Chrome 69.9%, IE 6.1% http://gs.statcounter.com/: Chrome 56.15%, IE 12.68% https://www.w3counter.com/globalstats.php: Chrome 57.2%, IE 9.6%
интересная заметка, я, пожалуй, ознакомлюсь с упомянутыми документами, т.к. несмотря на то, что написал уже не один десяток страниц технической документации на английском, в некоторых случаях все равно испытываю конфуз
в целом поддержу, но я бы поменял на «starting a server», т.к. серверов может быть много и пользователь читающий логи, вероятно, не знает, что это за сервер такой
моему нетбуку чуть больше полутора лет. на нем оригинально стояла win xp и был гиг оперативы. правда, винда была сразу заменена на убунту, а вот второй гиг оперивы я поставил только пару месяцев назад
авторизацию пользователя можно улучшить следующим образом:
1. сделать отдельно функцию, которая будет получать идентификатор сессии или какой-то другой токен, который будет уникально идентифицировать пользователя. затем передавать не логин и пароль пользователя, а этот идентификатор
2. данные авторизации (не важно, пару логин-пароль или идентификатор сессии) можно передавать не как один из аргументов функции, а в заголовке soap запроса. удобно это тем, что практически в любой библиотеке, работающей с soap (типа axis, php soap), есть возможность задать этот заголовок один раз, после чего он добавляется к каждому запросу. это облегчит жизнь разработчика
оба совета в свое время реализовал в SOAP API биллинговой системы, все были довольны :)
может быть, я плохо искал, но пока не нашел ответа. что там с клавиатурой в таких прошивках? мне очень нравится клавиатура htc sense. особенно нравится то, что нет необходимости целиться точно в клавиши, xt9 очень выручает — набор текста осуществляется быстро и легко. а вот родная андроидовская (щупал на самсунгах) как-то совсем не впечатляет
какое-то слабенькое исследование получилось. заставлять каждого участника читать один и тот же рассказ несколько раз — как-то странно. ведь раз от раза время прочтения будет несколько уменьшаться, а понимаение — увеличиваться. если же каждый испытуемый читал рассказ только один раз на одном из устройств, то получается для каждого устройства было произведено всего 8 измерений, это очень мало. люди ведь все читатют с разной скоростью. и при таком количестве измерений это могло оказать влияние
кроме того не приведено данных о скорости чтения с экрана монитора ПК
уж если экспериментировать, то, наверное, надо было сделать так. взять человек эдак 200. каждому дать прочитать один и тот же рассказ Хэммингуя в бумажном варианте. засечь время. а теперь все эти 200 человек поделить на четыре группы и в каждой группе для каждого участника измерить время чтения какого-нибудь другого рассказа Хэммингуя. желательно, чтобы размеры рассказов были примерно одинаковы. далее для каждого участника вычислить отношение времен чтения первого и второго рассказов. теперь по каждой группе усреднить этот показатель. после этого будет сравнивать эти средние значения и сделать вывод
Katana — это не только IIS, есть ещё self host вариант, пакет Microsoft.Owin.SelfHost
Взять к примеру ваше первое сравнение цен на топовые смартфоны — рост цены на 20% за 9 лет. Если зайти на сайт www.usinflationcalculator.com, то там есть удобный калькулятор изменения цен в USD в связи с инфляцией. За 2007 — 2016 годы цены выросли примерно на 16 процентов, т. е. реально ваши 20% на самом деле — это всего 4%, что в масштабе одного десятилетия кажется не очень существенным. Надо сказать, что этот мой анализ длиной в пару строк тоже довольно поверхностен, но уже из этого кажется понятным, что просто сравнивать цены в долларах — странная затея.
Дальнейшие рассуждения про сравнение ЖК мониторов на заре распространения с сегодняшим днем, а потом еще и с ЭЛТ (вообще другой товар с точки зрения технологий) — тоже ни о чем. Далее вы упоминаете спрос, производство и кокуренцию, но не говорите ни слова о том, как они на самом деле формируют цену в данном случае. Потом идет анализ изменения цен на другие товары, но изменение цен в рублях, т. е. как это вообще связать со всеми предыдущими выкладкими? В общем, извините, но слабо.
git checkout develop
git merge --squash feature/...
git commit -am '#issue comment'
git push origin develop
git branch -D feature/...
git push origin :feature/...
В итоге история у нас выглядит примерно так:
* <1234567> 2016-05-06 [dev1] (HEAD, origin/develop, develop) version bump
| * <1234567> 2016-05-06 [dev1] (tag: 1.52, master, origin/master) Merge branch 'develop'
| |\
| |/
|/|
* | <1234567> 2016-05-06 [dev1] #99 feature 99
* | <1234567> 2016-05-05 [dev2] #98 feature 98
* | <1234567> 2016-05-04 [dev1] version bump
| * <1234567> 2016-05-04 [dev1] (tag: 1.51) Merge branch 'develop'
| |\
| |/
|/|
* | <1234567> 2016-05-04 [dev1] #97 feature 96
* | <1234567> 2016-05-03 [dev2] #96 feature 97
* | <1234567> 2016-05-02 [dev1] version bump
| * <1234567> 2016-05-02 [dev1] (tag: 1.50) Merge branch 'develop'
| |\
| |/
|/|
* | <1234567> 2016-05-02 [dev1] #97 feature 96
* | <1234567> 2016-05-01 [dev2] #96 feature 97
Тут даже невооруженным взглядом видно, что происходило в проекте: кто, что и когда сделал, что и когда пошло в релиз.
Зачем нужны промежужточный коммиты в фиче бранче, вообще не понятно. За все три года работы по такой модели я ни от одного из коллег не слышал, что ему нужно было знать, что было в промежуточных коммитах.
http://www.w3schools.com/browsers/browsers_stats.asp: Chrome 69.9%, IE 6.1%
http://gs.statcounter.com/: Chrome 56.15%, IE 12.68%
https://www.w3counter.com/globalstats.php: Chrome 57.2%, IE 9.6%
habrahabr.ru/post/123244/
оно?
рапортовал о том, что вышел новый релиз, при попытке обновить появилось сообщение, которое уже не упоминало BETA, как было полчаса назад. обновляюсь
1. сделать отдельно функцию, которая будет получать идентификатор сессии или какой-то другой токен, который будет уникально идентифицировать пользователя. затем передавать не логин и пароль пользователя, а этот идентификатор
2. данные авторизации (не важно, пару логин-пароль или идентификатор сессии) можно передавать не как один из аргументов функции, а в заголовке soap запроса. удобно это тем, что практически в любой библиотеке, работающей с soap (типа axis, php soap), есть возможность задать этот заголовок один раз, после чего он добавляется к каждому запросу. это облегчит жизнь разработчика
оба совета в свое время реализовал в SOAP API биллинговой системы, все были довольны :)
кроме того не приведено данных о скорости чтения с экрана монитора ПК
уж если экспериментировать, то, наверное, надо было сделать так. взять человек эдак 200. каждому дать прочитать один и тот же рассказ Хэммингуя в бумажном варианте. засечь время. а теперь все эти 200 человек поделить на четыре группы и в каждой группе для каждого участника измерить время чтения какого-нибудь другого рассказа Хэммингуя. желательно, чтобы размеры рассказов были примерно одинаковы. далее для каждого участника вычислить отношение времен чтения первого и второго рассказов. теперь по каждой группе усреднить этот показатель. после этого будет сравнивать эти средние значения и сделать вывод