naXa!

я бы ещё посоветовал:
1) не называть взломщиков (и тем более скрипткидис) хакерами без разбора
2) понять, что вина лежит на вас, а не на нём
3) понять зачем он это сделал: чтобы показать вам уязвимость, на которую вы предпочли забить

Если вы хотите развиваться как программист, первое что стоит почитать - это основы алгоритмизации, которые закладывают базу разработчика, чего у вас судя по всему нет: поскольку многие считают, что это сегодня никому уже не надо. Языки это уже вторично: Js/Python/Ruby/Java/Go/Rust - если есть время, можно каждый глянуть по 2-4 недели на язык.

Все правильно делаете, все сначала копируют чужой опыт, не заморачивайтесь. Программист решает задачи, а не сочиняет код, пока для ваших задач достаточно гугла и чужих примеров, набьете руку на таком, будут и более сложные задачи.

Эффективности от конкретного языка где-то 20%. Остальные 80% это теория и нюансы конкретной предметной области. Поймите, что вся индустрия двигается 40-летними мужиками, которые эти ваши языки выучивают за неделю. А задачи написание эффективной и быстрой физики для игр или умного AI не могут решить уже более 30 лет. Учите теорию, математику, комбинаторику, алгоритмы и структуры данных. Языки меняются каждые 5-7 лет, а нерешенные задачи никогда.

очень эффективно , куча денег, слава, женщины.

Дам пару советов.
Совет первый - команде лучше собраться вместе на одной локации, это существенно мотивирует и упрощает коммуникации. Хакатон на дому - вообще какая-то стремная тема, хакатон хорошо удается, когда на одной локации работают несколько команд. Координация команды, которая работает в одном месте делается довольно очевидно.
При защите работы важно отправить на защиту человека, который хорошо умеет взаимодействовать с публикой и не боится публично выступать. Если такого человека нет - его надо идентифицировать и быстренько натренировать. Лучше всего устроить тестовый прогон защиты. Скорее всего, приложение не будет готово целиком - важно, чтобы защищающийся помнил, на какие кнопки при демонстрации надо жать, а на какие - жать не надо. Презентация продукта - ключевой момент, и оценка экспертов часто зависит не от качества самого продукта, а от качества презентации.

Все ваши вопросы решает Paymo.biz
Пользуюсь им уже два года, для команды меньше трех человек бесплатен.

Вопрос: что будет, если сферу быстро заморозить до -500? Процесс?

Заморозка остановится на температуре -273,15.
Поищите, что значит это число :)

Есть hack, есть dirty hack, есть monkey patch

Преподаю в школе информатику для 8, 9, 10 классов. Конечно есть разница в обучении школьников и студентов. Но для меня она не большая. Суть в том, что можно всем давать один и тот же материал, только школьникам в простой форме с простыми примерами, а студентам можно давать более сложные формы и со сложными примерами.

Самый выигрышный вариант, это:
Узнать то, что интересно обучаемым и разбирать эти примеры на практике. И чтобы было больше практике, в ходе которой вы дополняете теорию. Тогда теория лучше воспринимается и усваивается.

Эффект "wow". Вы что-то сделали и сразу видите результат.

Можно сколько угодно рассказывать ученикам, что такое интернет, ip, протоколы, и прочую теорию, все равно результат будет плачевный. Если у ученика есть интерес, желание, стремление, то он сам доучит все, что требуется в ходе разработки чего-то интересного.

Например, изучение слепого метода печати на клавиатуре. Вроде простая, но при этом нудная вещь. Как можно тут зародить интерес? Легко!
1. Ученикам приводится реальные примеры из жизни. Например, вы используете соц сети? Общаетесь с друзьями? (Задаются вопросы, чтобы выяснить интересы и чтобы на все вопросы ученик отвечал положительно). И в ответ приводятся примеры того, на что повлияет, если ученик научиться слепому методу печати.
2. Использовать игровой процесс. Игра и конкуренция. есть сайт клавогонки.ру, показывается как пример. Что там можно играть, можно покупать машинки и развиваться. Как покупать? Очень просто, чем лучше печатаете, тем больше денег.
Итог, с первого занятия, у учеников загораются глаза, азарт, они начинают соревноваться. На второй урок прибегают, чтобы сообщить у кого какая машины и какие результаты. И конечно же, сам результат - с не слепого метода 50 зн/мин, они через неделю уже печатают слепым методом 120-160 зн минуту.

Самое удивительное, ведь я сам в процессе игры с учениками, с моих 200 зн/мин ускорился до 470 зн/мин (слепой метод печати) за месяц (по 5-10 минут в день).
Когда меня учили на первом курсу слепому методу печати, первые 1-2 недели, были тихий ужас. Сидеть в Ворде набирать текст. Скукотища была та еще. Единственное, что подогревало интерес, это соревнование между одногруппниками и преподавателем. Все.

В общем, обучайте в процессе игры. :)

А то, что сейчас есть в программе школьной по информатике, это тихий ужас. Например, создать сайт с помощь Ворда... Или, сначала изучается, что такое БД, потом Паскаль, потом, что такое WWW.

Есть несколько разновидностей тестов. Если вы бэкэнд-разработчик, то вас, в первую очередь, будут интересовать два вида:

1. Юнит-тесты
2. Интеграционные тесты

Юнит-тесты — тесты, направленные на тестирование отдельных частей класса. Чаще всего это методы. Иногда — отдельные ветки методов (всегда справедливо для god objects).
Самый важный пункт: для юнит-тестирования не нужно поднимать контекст приложения! Вы тестируете логику отдельного юнита, а не связку классов. Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

Что покрывается юнит-тестами? В первую очередь покрывайте бизнес-логику (сервисы, классы-менеджеры). После — контроллеры. Можно покрыть DAO-слой (опять же, если там есть сложная логика)0.

Как пишется юнит-тест? Вы берёте набор входных параметров, мокаете классы-зависимости, передаёте входные параметры в тестируемый метод и проверяете выходные параметры. Если в методе есть условия — необходимо попасть во все ветки.

Писать ли отдельный тестовый метод для каждой ветки? Это зависит от вашего стиля и от того, планируете ли вы рефакторинг в ближайшем будущем. По-хорошему, стоит выделять отдельные крупные ветки в отдельные методы, особенно для god objects.

Интеграционные тесты — это тестирование нескольких взаимосвязанных классов. К примеру, класс бизнес-логики + DAO-класс.
В случае интеграционного теста вам придётся поднимать контекст приложения (обычно для этого создаются отдельные конфигурационные файлы). К тому же, будет неплохо настроить транзакционность на уровне отдельных методов (для того, чтобы не чистить базу руками после изменений).

Нужны более глубокие подробности — пишите :)

У меня есть пара саксесс-стори, не смотря на мой возраст :)
Несколько лет назад я занимался написанием ботов и просто утилит в виде юзерскриптов. И разрабатывал скрипт с кучей полезностей для vk.com. На базе этого скрипта получил несколько интересных знакомств и ценный опыт.

Так вот, ближе к делу. Однажды ко мне в личку постучался 19летний парень. Оказалось, что он очень сильно впечатлён самой возможностью «расширять сайты» и добавлять функционал. Он попросил меня рассказать ему, как это делается. У парня было только школьное образование, ни в ВУЗ, ни в ПТУ он не поступил, работы не было (на это были причины личного характера).
Его обучение началось с javascript. Я взял его в «команду» — помогать мне со скриптом. Со своей стороны я объяснял ему основы программирования на конкретных примерах: алгоритмическое мышление, циклы, условия, простые алгоритмы, и т.д.
Самое главное, что все эти понятия были наглядными. Имея в запасе минимальное понятие о API джаваскрипта, не представляя, что такое CSS и HTML, человек, тем не менее, мог видеть результат своих экспериментов, и этот результат приносил какую-то пользу, а не был очередным хеллоу-вордом.

Сейчас товарищ работает javascript-программистом в некой Московской фирме. Помимо джаваскрипта человек интересуется всеми сопутствующими технологиями — серверсайд языки, вёрстка, десктопные приложения, алгоритмы и далее по списку.

Как показывает опыт, основанный на экспериментах на друзьях, следующий паттерн работает для большинства заинтересованных:

1. Определить, что именно зацепило человека (с какими технологиями его начать знакомить в первую очередь)
2. Познакомить его с базовыми понятиями (циклы, переменные, условия, составление алгоритмов)
3. Дать ему в руки инструмент для экспериментов — простой язык, на котором можно писать полезные для самого человека вещи, с незамысловатым API.
4. Показывать человеку реальный пример кода (исправлять его код) и объяснять досконально ход своих мыслей при разработке или проектировании. При этом, сначала вы будете отвечать на вопросы «как?». Постепенно их нужно полностью сводить к вопросам «почему?». Вопрос «как» человек должен решать сам.
5. Максимально сократить цикл идея-реализация-результат. Это очень важно! Это топливо для мотивации.
6. Главный вопрос — какую идею реализовывать. It depends. Лучше всего, чтобы обучаемый сам придумывал, какую проблему он будет решать. Если мотивация не строится на мысли «мне срочно нужны деньги, поэтому я стану программистом» или прочими мыслями о будущем, то написания «шаблонных» программ будет идти в ущерб мотивации.
7. Как только человек научится ваять код самостоятельно — он начнёт выходить за рамки вашего обучения. Тут важно научить человека получать информацию (да, не все умеют пользоваться гуглом и стэковерфлоу. И про книги не забываем)


Это субъективно, но для меня такой подход работает. Я веб-программист, и «подопытные» тяготеют к этим технологиям.
Но в целом — никто не любит сухую теорию. Видеть и «щупать» результат — бесценно :)

Если Ваш «стартап» так крут, что необходимо задумываться о защите от рейдерства, регистрации товарного знака, минимизации налогов (при том, что до нескольких десятков миллионов рублей годового оборота российская УСН вполне даже ничего), то Вам следует обратиться в хорошую юридическую фирму — лучше всего в американскую или британскую.

Если же Ваш бизнес еще только на стадии идеи (прототипа), которая кажется Вам суперудачной и чрезвычайно привлекательной для рейдеров, то, имхо, Вам следует просто брать и ее реализовывать, а к страшилкам типа «вокруг одни рейдеры», «налоги превышают 100% и платить их невозможно» и т.п. относится критически. Иначе Вы рискуете потратить массу денег на создание основы того, что потом, возможно, и не будет реализовано.

Пользовался китайфоном полтора года. Нареканий не было, разве что перевод интерфейса операционки местами косячный.

Перестал пользоваться только потому, что его стырили. А так, наверное, дружил бы с ним до сих пор.