Если говорить о кардинальных отличиях, то еще, на мой взгляд, это поиск и команды. Благодаря умному поиску за несколько секунд можно любые задачи (при этом не надо знать никакой JQL), выделить задачи и применить нужные изменения за раз с помощью команд (это очень ускоряет работу с задачами).
О точно, это просто настолько естественно, что даже не сильно обращал внимания, просто вводил команду и делал дело
Ну кардинальных отличий и не будет, наверное, это все-таки 2 инструмента, которые выполняют одни и те же задачи. Когда пользовался им, более всего нравился встроенный тайм-трекинг из коробки, практически все задачи можно было выполнять не притрагиваясь к мыши, какие угодно и сколько угодно полей для задач, причем можно было еще и завимости между ними настроить(очень гибко и довольно просто), а вот с расширением функционала возникали проблемы, workflow editor был никакущий, да и не так уж много можно было с ним сделать.
Было бы здорово, если бы Вы после некоторого времени отписались, как это устройство в эксплуатации — сам задумался поставить систему приточной вентиляции, пока, правда смотрел в сторону бризеров
Java-да. Даже не сама виртуальная машина, а ее архитектура, которая описывается, насколько я помню в java blueprints(могу ошибаться) и доступна разработчикам сторонних виртуальных машин.
Насчет PHP — не согласен. Во-первых, потому что изначально php имел довольно низкий порог входа и быстрое получение результата, обусловленные в том числе и простотой синтаксиса. Во-вторых, вм php все же проигрывает jvm по производительности. Ну и в третьих, большинство споров, улучшений и прочего в мире php связаны не с расширением функционала стандартной библиотеки, ни с повышением производительности, а именно с добавлением различного синтаксического сахара и применения лучших паттернов проектирования(порой кажется, что мы пытаемся играть в серьезных ынтырпрайз разработчиков со всеми этими фабриками, добавлением дженериков, сложными архитектурами кода и прочим).
Но, нужно отдать должное, что многие нововведения касательно синтаксиса не навязываются разработчиками и не ломают обратную совместимость.
Поддерживаю хабратоварищей, которые просят рассказать о haiku. Очень интересно было бы узнать сферу ее возможного применения помимо десктопов, да и на десктопах тоже, какие плюсы/минусы относительно того же ubuntu?
Как уже выше отметили для некоторых случаев исключения — не лучший выход. А вот null все-таки очень универсальный тип, означающий «ничто».
Давайте рассмотрим примеры, когда корректно выбрасывать исключение, а когда все-таки лучше null(примеры очень субъективны, буду рад конструктивной критике):
Корректнее вернуть null, например, при работе с ORM, например, какой-нибудь абстрактный Model::findByPk($id). При этом лучше, если у нас будет возможность указать хинтом, экземпляр какого класса должен быть возвращен методом findByPk
Доступ к элементу связанного списка по индексу(хотя кто же на php использует связанные списки!). В этом случае лучше выбросить исключение. При этом возвращаемые значения могут быть определенного типа либо же любого типа.
<зануда>
PHP все-таки по умолчанию является слабо-типизированным языком с динамической типизацией. Да, в 7-ой версии должен появиться strict-mode, но по умолчанию он выключен. А то, о чем Вы говорите, является все-таки type-hinting'ом.
</зануда>
Ну а вообще, отсутствие возможности вернуть null — довольно сомнительный плюс, теперь вместо обычной проверки на null, например при использовании ORM, нужно будет городить велосипед. Да и вообще создается впечатление, что php пытается напялить на себя костюм джавы, постоянно усложняясь, а за ним идет и весь php-мир, за некоторыми исключениями. И вот это по-моему не очень хорошо, ведь основным преимуществом php была простота разработки.
Как-то имхо слишком много html-based фреймворков(мне лично приложения, написанные с использованием подобных библиотек ну очень сильно не нравятся). Было бы интересно узнать, какой процента разработчиков предпочитает именно такие технологии.
Ну вот сразу накинулись на человека, не объяснив почему.
Я признаюсь честно — не вдумывался в поведение кода, т.к. это тяжеловато, т.к. форматирования как такового нет. Если даже вы пишете код для себя, то стоит уделить внимание отступам и форматированию, чтобы в будущем было проще разобраться, не говоря уже о том, что вы его решили показать другим. Далее, данный пример очень субъективен и может быть повторно использован с большой натяжкой(js лучше было бы оформить в плагин для jquery, php в небольшой класс). По php-коду: конструкции с подавлением ошибок использовать очень опасно, об этом трубят на всех углах, также как и использовать mysq-функции(в качестве замены есть PDO или mysqli).
Это все бросается в глаза и вызывает волну негативных эмоций)) А ведь сегодня пятница. Надеюсь, качество вашего кода улучшится
Так вот кто автор этой чудесной программы! Дай Бог вам здоровья за столь полезную инициативу! Ибо для моего Зажоп Ставрополя и ближайших населенных пунктов найти программу с адекватными картами, да еще и бесплатную практически невозможно.
вот это скорее всего, однако, как мне кажется, версия для «домашнего» использования останется бесплатной. Платными будут продукты для корпоративной среды, выпущенные на базе virtualbox
О точно, это просто настолько естественно, что даже не сильно обращал внимания, просто вводил команду и делал дело
Уоу, Вы очень смелый человек, раз так самоотверженно рискуете виртуальным рейтингом
Насчет PHP — не согласен. Во-первых, потому что изначально php имел довольно низкий порог входа и быстрое получение результата, обусловленные в том числе и простотой синтаксиса. Во-вторых, вм php все же проигрывает jvm по производительности. Ну и в третьих, большинство споров, улучшений и прочего в мире php связаны не с расширением функционала стандартной библиотеки, ни с повышением производительности, а именно с добавлением различного синтаксического сахара и применения лучших паттернов проектирования(порой кажется, что мы пытаемся играть в серьезных ынтырпрайз разработчиков со всеми этими фабриками, добавлением дженериков, сложными архитектурами кода и прочим).
Но, нужно отдать должное, что многие нововведения касательно синтаксиса не навязываются разработчиками и не ломают обратную совместимость.
Давайте рассмотрим примеры, когда корректно выбрасывать исключение, а когда все-таки лучше null(примеры очень субъективны, буду рад конструктивной критике):
PHP все-таки по умолчанию является слабо-типизированным языком с динамической типизацией. Да, в 7-ой версии должен появиться strict-mode, но по умолчанию он выключен. А то, о чем Вы говорите, является все-таки type-hinting'ом.
</зануда>
Ну а вообще, отсутствие возможности вернуть null — довольно сомнительный плюс, теперь вместо обычной проверки на null, например при использовании ORM, нужно будет городить велосипед. Да и вообще создается впечатление, что php пытается напялить на себя костюм джавы, постоянно усложняясь, а за ним идет и весь php-мир, за некоторыми исключениями. И вот это по-моему не очень хорошо, ведь основным преимуществом php была простота разработки.
Я признаюсь честно — не вдумывался в поведение кода, т.к. это тяжеловато, т.к. форматирования как такового нет. Если даже вы пишете код для себя, то стоит уделить внимание отступам и форматированию, чтобы в будущем было проще разобраться, не говоря уже о том, что вы его решили показать другим. Далее, данный пример очень субъективен и может быть повторно использован с большой натяжкой(js лучше было бы оформить в плагин для jquery, php в небольшой класс). По php-коду: конструкции с подавлением ошибок использовать очень опасно, об этом трубят на всех углах, также как и использовать mysq-функции(в качестве замены есть PDO или mysqli).
Это все бросается в глаза и вызывает волну негативных эмоций)) А ведь сегодня пятница. Надеюсь, качество вашего кода улучшится
ЗажопСтаврополя и ближайших населенных пунктов найти программу с адекватными картами, да еще и бесплатную практически невозможно.