Даже если код был написан другом (или найден в интернете), человеку в любом случае придется проходить собеседование и там его расколят быстро. Собеседование — это как в том анекдоте. Беседа двух умных людей. Если среди них есть ровно один идиот, кандидат пойдет искать другое место :)
По этому фрагменту можно понять «возраст» программиста. Если вместо изящного класса вам приходит неструктурированная простыня — это залет. Если объект как осьминог оброс странными методами вместо понятного интерфейса, если человек не пользуется шаблонами и т.д. — это минус. Если хочется, можно найти в коде пару спорных мест и разузнать, почему кандидат сделал это именно так. Бывает интересно. В общем, по коду человека можно сказать гораздо больше, чем по его резюме.
Еще одно, как минимум для программистов. Вы никогда не найдете работодателя, который будет давать задачи исключительно мирового масштаба, интересные и великие, и никогда — рутинные. Если Вы приходите на собеседование без этого понимания, Ваши шансы могут серьезно пострадать.
Хотелось бы добавить:
Будьте адекватны. Трезво оцените, подходите ли Вы со своими навыками и знаниями под вакансию. Хотя бы наполовину. Если подходите, или же есть здоровые сомнения — попробуйте. Если нет — не отправляйте резюме. Даже если вы его адаптируете под запросы работодателя, чтобы не так бледно выглядело. Ну если не охота конечно почуствовать себя полным кретином, когда нечего ответить на очередной «детский» вопрос на собеседовании.
ну почему же. Товарисч уже нахватал советов, я думаю что информация к размышлению у него уже есть :) Иногда нужен просто толчок в нужном направлении, и все будет хорошо.
А по поводу изменения длины поля — в любом случае, тот же MySQL может эффективнее строить временные таблицы, если поле имеет небольшую длину. А уж если на тот же varchar(255) еще и хочется индекс накинуть, то лучше понять какая длина там будет реально использоваться и урезать поле. Чем короче запись индекса, тем больше их влезет в память и тем быстрее по такому индексу ползать.
Не бенчмаркал, насколько работает на практике в наше время, но слышал что СУБД могут применять более шустрые алгоритмы для поиска записей, если в таблице длина каждого поля четко определена (CHAR, INT и т. д.). В этом случае запись всегда имеет одну и ту же длину и запись в файле ищется по принципу N*LEN, где LEN — длина записи, N — ее номер по порядку в файле. На всякий случай делаю таблицы фиксированными там, где разница в размере не будет заметна или отсутствует :)
У нас пока еще есть вакансия подавана-перлиста. Таймлимит на рост из подаванов в девелоперы — полгода. Если кому интересно, могу рассказать подробнее, но не уверен, что это стоит делать прямо в данном топике. Пишите личкой.
По поводу паролей на хабре недавно уже пролетало: habrahabr.ru/blogs/webdev/39079/
Только обязательно прочитайте комментарии, там лечатся некоторые недочеты статьи.
По поводу остального. Я не большой специалист по пхп, поэтому советы будут достаточно общими.
0) отделите уже данные от их представления. Шаблонизаторы рулят
1) познакомьтесь поближе с ООП. Если не понравится, в любой момент вернетесь назад. Потом. Если захочется (с)
2) один из китов ООП это инкапсуляция. Объект сам умеет делать все необходимые операции, и предоставляет наружу ОГРАНИЧЕННЫЙ интерфейс. Например, у нас есть объект «юзер», с его данными — id, фио, логин, пароль. Это будут свойства объекта. Что можно сделать с юзером? Загрузить его по id, по логину, по фио, проверить пароль, поменять фио, поменять пароль, создать нового юзера наконец, ну и удалить. Вот вам набор методов. Немного подумав о том, на кой черт нам такой большой набор, можно его сократить, скажем так: загрузить по любому полю/набору полей, поменять любые поля, создать, удалить, проверить пароль. Еще немного подумав, можно ввести операцию сохранения данных, которая сама будет решать, поменять поля у существующего юзера или создать нового. А подумав окончательно Вы заметите, что этот набор методов на 90% подходит к любому другому объекту, храящемуся БД или любом другом хранилище.
3) попробуем применить это скажем к хранилищу статей. Статьи можно выбирать не по одной, а сразу несколько (хм, ага, кстати юзеров тоже — в панели управления), статью можно править (создавать/изменять), ее можно удалить и ее можно показать клиенту. Черта с два ее можно показать, мы же договорились отделить логику и данные от представления! И вообще это забота приложения, а не самого объекта, который у нас делает базовые операции по управлению данными.
4) поглядев на эту красоту, вы заметите что и основные запросы к базе часто делаются по одной схеме и их можно утащить в суперкласс
5) кстати, мы уже незаметно написали что-то похожее на фреймворк :) Это ничего что он возможно кривоват и вообще велосипед. Это — отличная зарядка для ума.
6) интерфейс у всех Ваших объектов идентичен, и вы становитесь способны делать некоторые забавные вещи, скажем сделать единственную страницу в админке, которая будет уметь править любую таблицу в бд — нужно только передать ей название класса и идентификатор записи. Вопросы безопасности и разделения доступа оставим за кадром — они решаются.
7) всегда минимизируйте интерфейс объекта
8) всегда делите систему на максимально независимые части. Иерархичные связи типа «Компания-работники» и т. д. организуются на объектах без проблем. Неиерархичные связи часто лучше делать, не вкрячивая их в объекты, чтобы не увеличивать связанность системы. Чем меньше один объект или тесно связанная группа знает про другие группы — тем проще и главное надежнее все будет работать. Если связь нужна, можно реализовать ее на уровне приложения либо даже ввести отдельные классы специально для управления сложным хозяйством, смотрите по обстановке.
9) чтобы повысить прозрачность системы, всегда делите систему на слои — что нужно объекту, что приложению, и не смешивайте слои в одном классе
10) не стесняйтесь писать велосипеды, и не стесняйтесь сравнивать свои велосипеды с чужими, чтобы знать куда идти дальше. Если бы велосипедов не было, мы бы сейчас имели один убогий шаблонизатор, одну бд и один язык программирования.
Мой опыт говорит, что облако очень удобно, когда заходишь на новый ресурс и сразу видишь его направленность. Например, с месяц назад на хабре пролетал веб2.0 проект для программистов. Зашел, посмотрел на облако - одни, простите, виндузятники. Не мое. Ушел. А для кого-то наоборот.
А на знакомом ресурсе как правило уже знаешь, что где искать.
Это постановление в данный момент не действует. В начале года вышла новая редакция закона о защите прав, и в результате технически сложные изделия возвращать можно.
Тут народ уже упомянул VirtualDub, Avidemux, MEncoder... Если не сложно, есть какие-нибудь преимущества этой софтины перед ними? Так сказать, то, из-за чего на нее стоило бы перейти?
Я предпочитаю покупать книги в качественном исполнении (переплет там, бумага чтоб не газетная и т.д.) - чтобы приятно было даже брать в руки. Такие потом отдавать жалко, даже если не пошлО :) Но вообще инициатива интересная, спасибо.
Будьте адекватны. Трезво оцените, подходите ли Вы со своими навыками и знаниями под вакансию. Хотя бы наполовину. Если подходите, или же есть здоровые сомнения — попробуйте. Если нет — не отправляйте резюме. Даже если вы его адаптируете под запросы работодателя, чтобы не так бледно выглядело. Ну если не охота конечно почуствовать себя полным кретином, когда нечего ответить на очередной «детский» вопрос на собеседовании.
Теперь, как я понимаю, уже не поправить?
Только обязательно прочитайте комментарии, там лечатся некоторые недочеты статьи.
По поводу остального. Я не большой специалист по пхп, поэтому советы будут достаточно общими.
0) отделите уже данные от их представления. Шаблонизаторы рулят
1) познакомьтесь поближе с ООП. Если не понравится, в любой момент вернетесь назад. Потом. Если захочется (с)
2) один из китов ООП это инкапсуляция. Объект сам умеет делать все необходимые операции, и предоставляет наружу ОГРАНИЧЕННЫЙ интерфейс. Например, у нас есть объект «юзер», с его данными — id, фио, логин, пароль. Это будут свойства объекта. Что можно сделать с юзером? Загрузить его по id, по логину, по фио, проверить пароль, поменять фио, поменять пароль, создать нового юзера наконец, ну и удалить. Вот вам набор методов. Немного подумав о том, на кой черт нам такой большой набор, можно его сократить, скажем так: загрузить по любому полю/набору полей, поменять любые поля, создать, удалить, проверить пароль. Еще немного подумав, можно ввести операцию сохранения данных, которая сама будет решать, поменять поля у существующего юзера или создать нового. А подумав окончательно Вы заметите, что этот набор методов на 90% подходит к любому другому объекту, храящемуся БД или любом другом хранилище.
3) попробуем применить это скажем к хранилищу статей. Статьи можно выбирать не по одной, а сразу несколько (хм, ага, кстати юзеров тоже — в панели управления), статью можно править (создавать/изменять), ее можно удалить и ее можно показать клиенту. Черта с два ее можно показать, мы же договорились отделить логику и данные от представления! И вообще это забота приложения, а не самого объекта, который у нас делает базовые операции по управлению данными.
4) поглядев на эту красоту, вы заметите что и основные запросы к базе часто делаются по одной схеме и их можно утащить в суперкласс
5) кстати, мы уже незаметно написали что-то похожее на фреймворк :) Это ничего что он возможно кривоват и вообще велосипед. Это — отличная зарядка для ума.
6) интерфейс у всех Ваших объектов идентичен, и вы становитесь способны делать некоторые забавные вещи, скажем сделать единственную страницу в админке, которая будет уметь править любую таблицу в бд — нужно только передать ей название класса и идентификатор записи. Вопросы безопасности и разделения доступа оставим за кадром — они решаются.
7) всегда минимизируйте интерфейс объекта
8) всегда делите систему на максимально независимые части. Иерархичные связи типа «Компания-работники» и т. д. организуются на объектах без проблем. Неиерархичные связи часто лучше делать, не вкрячивая их в объекты, чтобы не увеличивать связанность системы. Чем меньше один объект или тесно связанная группа знает про другие группы — тем проще и главное надежнее все будет работать. Если связь нужна, можно реализовать ее на уровне приложения либо даже ввести отдельные классы специально для управления сложным хозяйством, смотрите по обстановке.
9) чтобы повысить прозрачность системы, всегда делите систему на слои — что нужно объекту, что приложению, и не смешивайте слои в одном классе
10) не стесняйтесь писать велосипеды, и не стесняйтесь сравнивать свои велосипеды с чужими, чтобы знать куда идти дальше. Если бы велосипедов не было, мы бы сейчас имели один убогий шаблонизатор, одну бд и один язык программирования.
Как-то так :)
А на знакомом ресурсе как правило уже знаешь, что где искать.