Думаю, тема различия Ko3.0 и Ko3.1 и так неплохо развита во всевозможных блогах, форумах, сообществах, связанных с Kohana. Однако, если у Вас есть какие-то конкретные вопросы, или идеи для статьи на эту тему — задавайте, постараюсь ответить.
Как раз закончились недавно и мои поиски — прошел много собеседований, получил много предложений… И вот ни разу еще не удалось узнать, что же за человек то такой — этот HR. Все проходило по двум сценариям:
1) Я откликаюсь на резюме (на том же hh, например), мне либо дают сразу отказ, либо высылают тестовое задание (почти все компании просили выполнить тестовое задание — с одной стороны я считаю это хорошей возможностью показать себя таким, каким меня не видно из резюме, но с другой стороны, когда таких заданий выходило много в короткий период — а они, как правило, были с фиксированным временем выполнения — приходилось выбирать лишь самые интересные вакансии), после его выполнения меня приглашают на собеседование, где мы общаемся либо с одним тимлидом, либо с ним и каким-нибудь дополнительным сильным специалистом.
2) Со мной связываются, (опционально) предлагают выполнить задание, приглашают на собеседование. Таких случаев было 2 — в одном меня собеседовала вся (!!) команда разработчиков, во втором — руководитель компании и менеджер с привлечением специалиста со стороны (для оценки моего технического уровня)
А вот на живого эйчара так и не довелось посмотреть за 2 недели поиска работы и 8 прошедших собеседований :(
Не знаю, как у вас там в Зенде, но буду сильно удивлен, получив отрицательный ответ:
неужели нельзя расширить класс и дополнить его методами (and_)where_open, (and_)where_close?
У меня база статистики одного проекта пожирает в среднем 20-30гб/месяц при небольшом траффике. А другая база — приложения, для которого ведется статистика, состоит из нескольких десятков таблиц связанных между собой чуть более, чем полностью. Так что пишите — будет очень интересно почитать про работу с объемными как по весу, так и по архитектуре базами данных.
Синтаксис может быть любым — изучить синтаксис одного языка, имея опыт работы с другим, не составит проблем при схожей семантике. А вот кардинально различная семантика — это уже другой вопрос.
Если пожертвовать красотой и несколькими строчками, то можно решить задачу вот так.
В Вашем варианте отдельное условие для вывода FizzBuzz необосновано.
for ($i = 1; $i <= 30; $i++)
{
if (($i % 3 != 0) AND ($i % 5 != 0)) echo $i;
else
{
if ($i % 3 == 0) echo 'Fizz';
if ($i % 5 == 0) echo 'Buzz';
}
echo '
';
}
1) Я откликаюсь на резюме (на том же hh, например), мне либо дают сразу отказ, либо высылают тестовое задание (почти все компании просили выполнить тестовое задание — с одной стороны я считаю это хорошей возможностью показать себя таким, каким меня не видно из резюме, но с другой стороны, когда таких заданий выходило много в короткий период — а они, как правило, были с фиксированным временем выполнения — приходилось выбирать лишь самые интересные вакансии), после его выполнения меня приглашают на собеседование, где мы общаемся либо с одним тимлидом, либо с ним и каким-нибудь дополнительным сильным специалистом.
2) Со мной связываются, (опционально) предлагают выполнить задание, приглашают на собеседование. Таких случаев было 2 — в одном меня собеседовала вся (!!) команда разработчиков, во втором — руководитель компании и менеджер с привлечением специалиста со стороны (для оценки моего технического уровня)
А вот на живого эйчара так и не довелось посмотреть за 2 недели поиска работы и 8 прошедших собеседований :(
неужели нельзя расширить класс и дополнить его методами (and_)where_open, (and_)where_close?
P.S.: привет от Kohana.
ОС была предустановлена на ноуте.
I'm feeling lucky =)
А в начале 30 вместо 100 — это у меня экран на ноуте маленький, на 100 записях скролл появится...))
В Вашем варианте отдельное условие для вывода FizzBuzz необосновано.