большое обновление для Windows 10… так ОС стала загружаться на 30% быстрее по сравнению с Windows 7 на тех же устройствах.
в контексте новости об обновлении самой Windows 10, хотелось бы увидеть сравнение с Windows 10 до обновления, а не с Windows 7. Опять какой-то маркетинговый булшит получается.
«интересен процесс выбора фич для новых релизов, разработки и тестирования?» — глосую за этот пункт!
И ещё интересно, используете ли вы какие-то статические анализаторы кода (типа PVS Studio) или «санитайзеры» (о которых часто слышу упоминания в новостях про исправленные баги в Chrome)?
Смотрели ли вы на такие свежие и модные технологии, как Rust и Go? (безопасная работа с памятью и хорошая поддержка параллелизма)
bsl — движок исполнения встроенного языка — медленно, очень медленно товарищи! Стоит ли вопрос производительности в планах и с каким приоритетом? Как насчёт многопоточности?
Да, вода водой. Можно заменить Dart на ClojureScript или Elm и т.п. — все говорят одно и тоже: «нас мало, зато у нас очень дружелюбное комьюнити профессионалов и мы компилируемся в кроссбраузерный js, не нужно думать о совместимости».
setReadDataOnly(true) — это не запрет на изменение, это команда для ридера «прочитай из исходного файла только данные без стилей» — ускоряет чтение, уменьшает потребление памяти. О нём, кстати, написано в той статье Универсальное чтение ячеек в PHPExcel
//Берём лист из оригинального файла
$sheet = $sheetsIterator->current();
//"Перекладываем" его в PhpExcel объект, который потом будет сохранён в CSV
$csvPagePhpExcel->addSheet($sheet, 0);
В примечание к своему примеру скажу, что помимо метода addSheet() есть ещё addExternalSheet() — в общем случае более верным будет использовать именно addExternalSheet(), т.к. он копирует ещё и стили, которые хранятся не в объекте $sheet, а в самом workbook. Но для данной задачи вывода в CSV стили не важны, поэтому использование addSheet() будет быстрее и проще.
Разница с вашим кодом есть: копируя листы целиком, я никак не могу задать форма вывода дат. Будет использован некий формат «по умолчанию», который может отличаться от файла к файлу. Я попробовал два файла из своих реальных таблиц, в одном из них был FORMAT_DATE_XLSX14, в другом FORMAT_DATE_YYYYMMDD2.
Второе отличие: в вашем коде происходит хитрая проверка на ошибки в формулах (которые могут ссылаться на внешние книги), в моём варианте этих проверок нет.
Провёл тест вашего кода и своего кода на большом файле из 170 листов и 9.5 Мб результирующего CSV текста:
ваш вариант: 3221 сек
мой вариант: 347 сек.
p.s. пока писал комментарий, подумал, что перекладывать лист в промежуточный PhpExcel объект для записи в CSV вообще не обзательно, можно писать в CSV на лету из исходного PhpExcel объекта, двигая указатель текущего листа ($objWriter->setSheetIndex($sheetsIterator->key())): gist.github.com/pqr/ad12493947e7b1e2910f/1698b405fb511b4fc625a95139d3c23c3a21bd5d
отработал за 321 сек.
Вопрос не к переводчику, а к автору (поэтому риторический), но зачем замазывать свой публичный ключ на скриншотах? На то он и публичный, что его может увидеть любой без ущерба безопасности.
Сам использую Flux подход и мне нравится, как он привносит понятную структуру и большую прозрачность в происходящее.
Но что я не люблю в таких статьях, так это упрощение типа «посмотрите на MVC — всё влияет на всё, куча стрелочек во все стороны, а теперь посмотрите на Flux — все стрелочки one way!», типа такого:
Но давайте посмотрим на Flux объективно:
1) у нас не один «прямоугольничек» View, их много — это целая иерархия React компонент
2) каждый View (React компонент) может генерировать Action
3) все Action проходят через единый Dispatcher, но если взглянуть на эту ситуацию как она есть на самом деле: каждый Action может быть обработан несколькими Store, каждый Store может обработать несколько Action — тут всё та же паутина стрелочек many-to-many между Action и Store
4) Store могут зависеть от других Store через механизм waitFor — это и есть каскадные обновления, только завёрнутые в промисы
5) Каждый Store может влиять на рендринг одного или нескольких View, а каждый View может зависеть от нескольких Store — опять паутина many-to-many стрелочек
6) И, наконец, рендринг одних View влияет на другие View, ведь это иерархия React компонент
Вот как это выглядит:
А теперь попробуйте на картинке про MVC взять все стрелочки, которые нарисованы влево (от View к Mode) и нарисовать их по большой дуге по часовой стрелке, вставив по пути квадратики «Action» — получается Flux!
Иными словами: Flux — это такой правильно нарисованный MVC с переименованными терминами (Model -> Store, Controller -> Action Creator + Dispatcher).
P.S. я не против Flux, я только за! Я против упрощений в попытках сравнить MVC и Flux, с которых начинается каждая первая статья про Flux.
Тоже хотел задать вопрос про PHP 7! И выйдет он очень скоро и в первом же посте на хабре будут комменты «а есть ли он на каком-нибудь shared-хостинге?» — думаю, вам стоит подсуетиться, чтобы выкатить PHP 7 в день релиза!
Ещё обратите внимание на относительно популярный в PHP кругах репозиторий с информацией о версиях PHP на разных хостингах: github.com/philsturgeon/phpversions.info — можете отправить им Pull Request, добавив себя в таблицу.
Кстати, на shared хостинге Ru-Center (http://hosting.nic.ru/) можно настраивать конфиг nginx под себя — лично пользуюсь. Как это у них технически сделано и что будет, если я напишу кривой конфиг не знаю.
И ещё интересно, используете ли вы какие-то статические анализаторы кода (типа PVS Studio) или «санитайзеры» (о которых часто слышу упоминания в новостях про исправленные баги в Chrome)?
Смотрели ли вы на такие свежие и модные технологии, как Rust и Go? (безопасная работа с памятью и хорошая поддержка параллелизма)
bsl — движок исполнения встроенного языка — медленно, очень медленно товарищи! Стоит ли вопрос производительности в планах и с каким приоритетом? Как насчёт многопоточности?
habrahabr.ru/search/?q=[nim] — 5 публикации (говорят, лучший язык программирования! habrahabr.ru/post/260149)
habrahabr.ru/search/?q=[visual basic] — 6 публикаций
habrahabr.ru/search/?q=[pascal] — 16 публикаций
habrahabr.ru/search/?q=[clojure] — 57 публикации
habrahabr.ru/search/?q=[groovy] — 58 публикаций
habrahabr.ru/search/?q=[lisp] — 72 публикации
habrahabr.ru/search/?q=[swift] — 84 публикации
habrahabr.ru/search/?q=[scala] — 146 публикаций
habrahabr.ru/search/?q=[delphi] — 185 публикаций
habrahabr.ru/search/?q=[bash] — 208 публикаций
habrahabr.ru/search/?q=[perl] — 309 публикаций
habrahabr.ru/search/?q=[c] — 513 публикаций
habrahabr.ru/search/?q=[c#] — 812 публикаций
habrahabr.ru/search/?q=[c++] — 936 публикаций
habrahabr.ru/search/?q=[python] — 1000 публикаций
habrahabr.ru/search/?q=[java] — 1000 публикаций
habrahabr.ru/search/?q=[javascript] — 1000 публикаций
habrahabr.ru/search/?q=[php] — 1000 публикаций
Поиск выдаёт максимум 1000 публикаций, нужно применить API, кто хочет заняться?
habrahabr.ru/search/?q=[dart] — 43 публикаций
habrahabr.ru/search/?q=[rust] — 56 публикаций
habrahabr.ru/search/?q=[go] — 113 публикаций
habrahabr.ru/search/?q=[ruby on rails] — 529 публикаций
В примечание к своему примеру скажу, что помимо метода addSheet() есть ещё addExternalSheet() — в общем случае более верным будет использовать именно addExternalSheet(), т.к. он копирует ещё и стили, которые хранятся не в объекте $sheet, а в самом workbook. Но для данной задачи вывода в CSV стили не важны, поэтому использование addSheet() будет быстрее и проще.
Разница с вашим кодом есть: копируя листы целиком, я никак не могу задать форма вывода дат. Будет использован некий формат «по умолчанию», который может отличаться от файла к файлу. Я попробовал два файла из своих реальных таблиц, в одном из них был FORMAT_DATE_XLSX14, в другом FORMAT_DATE_YYYYMMDD2.
Второе отличие: в вашем коде происходит хитрая проверка на ошибки в формулах (которые могут ссылаться на внешние книги), в моём варианте этих проверок нет.
Провёл тест вашего кода и своего кода на большом файле из 170 листов и 9.5 Мб результирующего CSV текста:
ваш вариант: 3221 сек
мой вариант: 347 сек.
p.s. пока писал комментарий, подумал, что перекладывать лист в промежуточный PhpExcel объект для записи в CSV вообще не обзательно, можно писать в CSV на лету из исходного PhpExcel объекта, двигая указатель текущего листа ($objWriter->setSheetIndex($sheetsIterator->key())): gist.github.com/pqr/ad12493947e7b1e2910f/1698b405fb511b4fc625a95139d3c23c3a21bd5d
отработал за 321 сек.
Наконец, не плохо было бы установить флаг $objReader->setReadDataOnly(true): gist.github.com/pqr/ad12493947e7b1e2910f/dd57ff58a2f7952e5beae491d95b3c8bc378dd66
отработал за 152 сек.
А вообще отличный мини-обзор на опыт использования Rust получился, пишите ещё!
Но что я не люблю в таких статьях, так это упрощение типа «посмотрите на MVC — всё влияет на всё, куча стрелочек во все стороны, а теперь посмотрите на Flux — все стрелочки one way!», типа такого:
Но давайте посмотрим на Flux объективно:
1) у нас не один «прямоугольничек» View, их много — это целая иерархия React компонент
2) каждый View (React компонент) может генерировать Action
3) все Action проходят через единый Dispatcher, но если взглянуть на эту ситуацию как она есть на самом деле: каждый Action может быть обработан несколькими Store, каждый Store может обработать несколько Action — тут всё та же паутина стрелочек many-to-many между Action и Store
4) Store могут зависеть от других Store через механизм waitFor — это и есть каскадные обновления, только завёрнутые в промисы
5) Каждый Store может влиять на рендринг одного или нескольких View, а каждый View может зависеть от нескольких Store — опять паутина many-to-many стрелочек
6) И, наконец, рендринг одних View влияет на другие View, ведь это иерархия React компонент
Вот как это выглядит:
А теперь попробуйте на картинке про MVC взять все стрелочки, которые нарисованы влево (от View к Mode) и нарисовать их по большой дуге по часовой стрелке, вставив по пути квадратики «Action» — получается Flux!
Иными словами: Flux — это такой правильно нарисованный MVC с переименованными терминами (Model -> Store, Controller -> Action Creator + Dispatcher).
P.S. я не против Flux, я только за! Я против упрощений в попытках сравнить MVC и Flux, с которых начинается каждая первая статья про Flux.
Ещё обратите внимание на относительно популярный в PHP кругах репозиторий с информацией о версиях PHP на разных хостингах: github.com/philsturgeon/phpversions.info — можете отправить им Pull Request, добавив себя в таблицу.