macrodef-ы удобно использовать совместно с пространствами имен, тогда вместо <copy_by_pattern /> было бы что-то вроде <my:copy /> + если в файле содержатся только макросы в качестве корневого тега можно использовать antlib.
Примечание: в ANT до версии 1.8 не было локальных переменных. Записав в переменную значение, его потом нельзя изменить.
Неудобство обходится достаточно легко созданием уникальных свойств для каждой копируемой директории:
+ очень важно помнить о том, что @{from} не является переменной и при вызове макроса просто заменяется переданной строкой, это может приводить к проблемам при использовании совместно с задачей script, в этих случаях лучше использовать scriptdef.
Для охоты. Для самообороны — сомнительно, пока из сейфа достанешь + не забываем про наш самый гуманный суд в мире, которому вам придется доказывать, что при самообороне была законной. Т.е. самооборона только в самом крайнем случае, в остальных лучше газовый балон.
С jar-ами то все понятно — они изначально были для упаковки классов и ресурсов, а вот с phar-ами не совсем, т.к. если производительность теряется, то в большинстве случаев смысла в них нет (упаковывать лучше и проще в архивы).
В статье действительно очень хорошо описано как распаковывать и запаковывать
А это не первая статья про phar на хабре в которой подробно описаны действия с архивами, но нет столь же подробного объяснения зачем они нужны. Отсюда и вопросы.
Т.е. вместо десятка директорий (=пространств имен) содержащих по несколько сотен директорий и файлов можно положить всего десяток phar архивов и подключать файлы из них? Производительность при этом не пострадает? Или phar все же больше предназначен для создания инсталяторов (=распаковать файлы в нужно место)?
также будет углублена система работы с социальными ресурсами
Не понимаю — FF всегда был эдаким конструктором, из которого, с помощью расширений, можно было собрать то, что нужно именно тебе — зачем пихать непосредственно в него все эти функции для работы с соц. сетями, почему не сделать их в виде расширений? Надеюсь, их можно будет отключить.
Позволит избежать «Notice: Undefined offset: 1» если explode вернет меньше чем 2 элемента. Также можно использовать для указания значения по умолчанию (например, null сделать) для настроек вида «param» (пропущено '=значение').
А я и не говорил о том, что форки это недостаток или что это плохо — только о том, что это спорный момент (причины почему я так считаю — выше). Функционал удобный, но в некоторых случаях просто ненужный (форки без коммитов).
Да, возможно, пользуюсь я им не очень часто. Но еще раз повторюсь — я не против клонов/фоков и очень рад если они в конечном итоге позволяют сделать проект лучше.
Но вы же не будете отрицать того, что не все будут слать пул-реквесты? Возьмем, например, первый попавшийся проект:rails, форков — 1347, запросов — всего 199 (скорее всего я их не все нашел? + часть, возможно, были слиты без запросов). Более тысячи форков не влились и скорее всего не вольются в основной проект — тогда какая разница в том где они: на гитхабе или в локальной копии?
Посмотрите с другой стороны — если вы хотите чтобы ваш патч был принят вам придется придерживаться принятых в проекте стандартов кодирования и т.д. — т.о. патч предполагает гораздо большую ответственность. Форк же позволяются просто реализовать то что нужно здесь и сейчас — кому кроме авторов нужны подобные поделки? Никому. И именно поэтому я считаю, что их не должно быть — хочешь что-то по быстрому сделать — сделай, но в своей локальной копии. не нужно выкладывать это в паблик, бессмысленно. Если же, действительно хочешь помочь проекту — сделай нормально и создай запрос (патч ли это будет или пул-реквест не слишком важно. впрочем последнее, возможно, поудобнее).
Я не к тому что клоны это плохо. Ситуация мне видится следующим образом — вместо того, чтобы создать запрос и прислать патч к проекту, создается клон который допиливается автором до нужного ему (автору) состояния и где-то используется, а в дальнейшем просто забрасывается. Понятно, что разработчики оригинального проекта могут ничего не знают о тех новых фичах которые есть в клоне. Проходит время оригинальный проект развивается, а клон так и остается в том состоянии в котором оставил его автор — разница только в том, что оно сгинет не «где-то в потрохах домашнего клона репозитория», а в потрохах гитхаба.
Да и потом, мы же говорим о гите => самый лучший способ реализовать нужные фичи в локальной копии, и если эта попытка окажется полезной — запостить патч к оригинальному проекту. Даже если код не попадет в оригинальный репозиторий, его полезность намного выше — т.к. когда кому-то понадобится точно такая же фича поиск начнется с трекера проекта. А в то, что кто-то будет специально прерывать весь гитхаб в поисках неизвестного клона от Васи Пупкина я не верю.
Т.о. нет принципиальной разницы (в плане полезности кода) между локальной копией и клоном — обе практически бесполезны как для самого проекта так и для остальных пользователей (повторюсь — про старение кода тоже не нужно забывать, вероятность того что клон будет поддерживаться в актуальном состоянии не слишком высока).
(за кадром — есть ли доверие к Васиному коду? Почему тогда он не включен в проект? ...)
> ПЛИС это уже как-то совсем сурово.
Почему? Как мне кажется, особо сложных алгоритмов не требуется — на ней как раз логичнее делать (ну вот не вижу смысла здесь использовать МК — есть входные сигналы, по определенным функциям рассчитываются выходные, какого либо ветвления в алгоритме на первый взгляд нет). Тем более, от неё требуется только первичная обработка сигналов датчиков и поддержание равновесия + поддержка простейших команд (=движение). Все что сложее — уже можно реализовать на МК.
Последнее время тоже посещает мысль сделать квадракоптер… только начинал неспешно интересовать этой темой — а тут как раз цикл статей :)
1) Почему именно МК?
у меня была идея реализовать все управление движение на ПЛИСе — поддержание равновесия, обработка сигналов датчиков, управление движением и т.д. МК же оставить только высокоуровневые функции — лететь но направлению x.y.z со скоростью.
2) Печать плат на заказ — где, цены, как это происходит?
(может быть кто-то списком фирм подетелится, особеностями и т.д. и т.п.)
3) Выбор датчиков (гироскопов, акселерометра) — может какая табличка существует, сравнение? перевывать кучу даташитов желания мало.
4) Главный вопрос — а где детальки то покупать?
(smd элементы уже найдены на ebay, а вот останые микросхемы — непонятно — у нас в городе их точно нет)
5) Токарка и фрезерка — сам же и отвечу — идем на talks.guns.ru/, регистрируемся, ищем жителей своего города и узнаем у кого, где, почем и что можно выточить (если не удалось найти — смотрим в разделе объявлений, но скорее всего немного дороже выйдет)
> Ответ прост — mb_* во многих местах не работает и на ёё стабильность особо надеяться не стоит.
Практически везде использую — особых проблем не замечал.
> Об этом в 3 части будет.
По-моему, лучше было это во введении написать — сейчас похоже на «сделали велосипед» => «нашли для этого причину», обратная последовательность (подробно аргументированная) была бы логичнее.
Сравнение производительности вашего решения с mb_*, надеюсь, будет?
(хотя и так понятно, что оно совсем не радужное будет, но интересно)
Вашу энергию да в нужное русло… глядишь бы и в самом PHP нативная поддержка юникода бы появилась… эх, мечты.
<copy_by_pattern />было бы что-то вроде<my:copy />+ если в файле содержатся только макросы в качестве корневого тега можно использовать antlib.Неудобство обходится достаточно легко созданием уникальных свойств для каждой копируемой директории:
+ очень важно помнить о том, что
@{from}не является переменной и при вызове макроса просто заменяется переданной строкой, это может приводить к проблемам при использовании совместно с задачей script, в этих случаях лучше использовать scriptdef.Вы про сейф забыли (патроны тоже отдельно).
Для охоты. Для самообороны — сомнительно, пока из сейфа достанешь + не забываем про наш самый гуманный суд в мире, которому вам придется доказывать, что при самообороне была законной. Т.е. самооборона только в самом крайнем случае, в остальных лучше газовый балон.
А это не первая статья про phar на хабре в которой подробно описаны действия с архивами, но нет столь же подробного объяснения зачем они нужны. Отсюда и вопросы.
Т.е. вместо десятка директорий (=пространств имен) содержащих по несколько сотен директорий и файлов можно положить всего десяток phar архивов и подключать файлы из них? Производительность при этом не пострадает? Или phar все же больше предназначен для создания инсталяторов (=распаковать файлы в нужно место)?
Не понимаю — FF всегда был эдаким конструктором, из которого, с помощью расширений, можно было собрать то, что нужно именно тебе — зачем пихать непосредственно в него все эти функции для работы с соц. сетями, почему не сделать их в виде расширений? Надеюсь, их можно будет отключить.
Позволит избежать «Notice: Undefined offset: 1» если explode вернет меньше чем 2 элемента. Также можно использовать для указания значения по умолчанию (например, null сделать) для настроек вида «param» (пропущено '=значение').
Да, возможно, пользуюсь я им не очень часто. Но еще раз повторюсь — я не против клонов/фоков и очень рад если они в конечном итоге позволяют сделать проект лучше.
Но вы же не будете отрицать того, что не все будут слать пул-реквесты? Возьмем, например, первый попавшийся проект:rails, форков — 1347, запросов — всего 199 (скорее всего я их не все нашел? + часть, возможно, были слиты без запросов). Более тысячи форков не влились и скорее всего не вольются в основной проект — тогда какая разница в том где они: на гитхабе или в локальной копии?
Посмотрите с другой стороны — если вы хотите чтобы ваш патч был принят вам придется придерживаться принятых в проекте стандартов кодирования и т.д. — т.о. патч предполагает гораздо большую ответственность. Форк же позволяются просто реализовать то что нужно здесь и сейчас — кому кроме авторов нужны подобные поделки? Никому. И именно поэтому я считаю, что их не должно быть — хочешь что-то по быстрому сделать — сделай, но в своей локальной копии. не нужно выкладывать это в паблик, бессмысленно. Если же, действительно хочешь помочь проекту — сделай нормально и создай запрос (патч ли это будет или пул-реквест не слишком важно. впрочем последнее, возможно, поудобнее).
могутничего не знают о тех новых фичах которые есть в клоне. Проходит время оригинальный проект развивается, а клон так и остается в том состоянии в котором оставил его автор — разница только в том, что оно сгинет не «где-то в потрохах домашнего клона репозитория», а в потрохах гитхаба.Да и потом, мы же говорим о гите => самый лучший способ реализовать нужные фичи в локальной копии, и если эта попытка окажется полезной — запостить патч к оригинальному проекту. Даже если код не попадет в оригинальный репозиторий, его полезность намного выше — т.к. когда кому-то понадобится точно такая же фича поиск начнется с трекера проекта. А в то, что кто-то будет специально прерывать весь гитхаб в поисках неизвестного клона от Васи Пупкина я не верю.
Т.о. нет принципиальной разницы (в плане полезности кода) между локальной копией и клоном — обе практически бесполезны как для самого проекта так и для остальных пользователей (повторюсь — про старение кода тоже не нужно забывать, вероятность того что клон будет поддерживаться в актуальном состоянии не слишком высока).
(за кадром — есть ли доверие к Васиному коду? Почему тогда он не включен в проект? ...)
Спорно — вместо присоединения к проекту плодятся десятки клонов, о которых не знает никто кроме их автора…
Почему? Как мне кажется, особо сложных алгоритмов не требуется — на ней как раз логичнее делать (ну вот не вижу смысла здесь использовать МК — есть входные сигналы, по определенным функциям рассчитываются выходные, какого либо ветвления в алгоритме на первый взгляд нет). Тем более, от неё требуется только первичная обработка сигналов датчиков и поддержание равновесия + поддержка простейших команд (=движение). Все что сложее — уже можно реализовать на МК.
рассуждения больше для себя
1) Почему именно МК?
у меня была идея реализовать все управление движение на ПЛИСе — поддержание равновесия, обработка сигналов датчиков, управление движением и т.д. МК же оставить только высокоуровневые функции — лететь но направлению x.y.z со скоростью.
2) Печать плат на заказ — где, цены, как это происходит?
(может быть кто-то списком фирм подетелится, особеностями и т.д. и т.п.)
3) Выбор датчиков (гироскопов, акселерометра) — может какая табличка существует, сравнение? перевывать кучу даташитов желания мало.
4) Главный вопрос — а где детальки то покупать?
(smd элементы уже найдены на ebay, а вот останые микросхемы — непонятно — у нас в городе их точно нет)
5) Токарка и фрезерка — сам же и отвечу — идем на talks.guns.ru/, регистрируемся, ищем жителей своего города и узнаем у кого, где, почем и что можно выточить (если не удалось найти — смотрим в разделе объявлений, но скорее всего немного дороже выйдет)
Практически везде использую — особых проблем не замечал.
> Об этом в 3 части будет.
По-моему, лучше было это во введении написать — сейчас похоже на «сделали велосипед» => «нашли для этого причину», обратная последовательность (подробно аргументированная) была бы логичнее.
Сравнение производительности вашего решения с mb_*, надеюсь, будет?
(хотя и так понятно, что оно совсем не радужное будет, но интересно)
Вашу энергию да в нужное русло… глядишь бы и в самом PHP нативная поддержка юникода бы появилась… эх, мечты.