Серёжа Пономарёв aka stokito

Java & Grails developer

[Linkset] Защита от атаки подбора пароля (brute force attack)

Just few links about various implementations of password cracking with brute force.

Brute-force search (Полный перебор)

Password cracking (Взлом пароля)

Theory + C#
http://www.bryanrite.com/preventing-brute-force-attacks-on-your-web-login/

Ruby authlogic
https://github.com/binarylogic/authlogic/blob/master/test/session_test/brute_force_protection_test.rb?source=cc
Doc
http://rdoc.info/github/binarylogic/authlogic/Authlogic/Session/BruteForceProtection

Ruby flood control
https://github.com/nedski/flood/blob/master/test/flood_test.rb

Drupal Mitigating a brute force attack
https://groups.drupal.org/node/293943

Drupal 6 login_security
https://drupal.org/project/login_security

IMPROVEMENTS TO SECURITY IN DRUPAL 7
http://drupalscout.com/knowledge-base/improvements-security-drupal-7

What’s Drupal’s flooding system?
http://www.braahm.be/posts/playing-drupal%E2%80%99s-flooding-system

API
https://api.drupal.org/api/drupal/modules!user!user.module/function/user_login_final_validate/7
https://api.drupal.org/api/drupal/includes%21common.inc/function/flood_register_event/7

Drupal 8 test
http://drupalcontrib.org/api/drupal/drupal!core!modules!user!lib!Drupal!user!Tests!UserLoginTest.php/function/UserLoginTest%3A%3AtestPerUserLoginFloodControl/8

http://api.drupalize.me/api/drupal/function/UserLoginTestCase%3A%3AtestGlobalLoginFloodControl/7

FloodInterface
https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Flood!FloodInterface.php/interface/FloodInterface/8

Test
https://api.drupal.org/api/drupal/core!modules!system!lib!Drupal!system!Tests!System!FloodTest.php/8

Grails
http://grails.org/plugin/bruteforce-defender

Оставить комментарий »

[Linkset] Groovy Puzzlers: assert «${‘test’}».equals(‘test’) will fail?

http://stackoverflow.com/questions/9682206/groovy-different-results-on-using-equals-and-on-a-gstringimpl
http://groovy.codehaus.org/Operator+Overloading
http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html

http://blackdragsview.blogspot.fr/2015/02/getting-rid-of-compareto-for.html

Оставить комментарий »

[Linkset] «Stringly typed» Antipatern: Avoid string where other types are more appropriate

http://habrahabr.ru/qa/13792/
http://cyrille.martraire.com/2010/01/the-string-obsession-anti-pattern/
http://monospacedmonologues.com/post/11534596516/stringly-typed
http://world.episerver.com/Blogs/Valdis-Iljuconoks/Dates/2012/1/Stringly-typed-Composer-functions/
http://blog.rough-sea.com/2010/10/from-a-stringly-typed-to-a-strongly-typed-messaging-system-part-i/
http://habrahabr.ru/blogs/programming/111432/
http://habrahabr.ru/blogs/development/96978/
http://blog.lexspoon.org/2010/05/stringly-typed-code.html
http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

http://en.wikipedia.org/wiki/Strong_and_weak_typing

Effective Java»: Item 50: Avoid string where other types are more appropriate

И ещё моя статья по теме: toString() contract

Оставить комментарий »

[Linkset] Несколько статей про карьеру в IT

Немного ссылок которые завалялись в закладках для неспешного чтива в обеденный перерыв

The Myth of the Genius Programmer

Чичиков и программиат

What I Wish I Knew When I Started My Career as a Software Developer

The Parable of the Two Programmers

Страсть к программированию. Глава 13. Найди ментора

Дисциплина, или этот проклятый рабочий день

10 отличий между хорошим и нормальным программистом

Как правильно задать вопрос своему коллеге?

Плохие привычки программистов

Признаки плохого программиста

Ремесло программиста. Золотые правила

Как стать руководителем

Что нужно делать смолоду или как стать богатым айтишником

Как стать богатым айтишником — продолжение от другого автора

5 Questions Great Job Candidates Ask

Оставить комментарий »

Что спрашивают на собеседованиях Senior Java Developers?

За прошлые две недели я прошёл больше двадцати собеседований. Может больше, может меньше, сложно сказать, большинство из них проходил по скайпу «вот прям сейчас». Ещё пару таких неделек и я бы побил рекорд комбатса :)
Немного вестей с полей, очень субъективно:
* Мне сложно судить, но ощущение что вакансий по Java в Киеве заметно поубавилось. Судить сложно, потому что в прошлый раз когда искал работу я был мидл уровня и был не очень востребованным на рынке. Ну и проект в прошлый раз я нашёл за день, там искали именно специалиста по Grails как раз как я.
Но в любом случае, новые компании не могут аутсорсить в Украину. Многие делают массовый релокейт своих сотрудников. Массово и планомерно сгребают всех в Таллин и Краков.
* В этот раз по Grails не смог найти ничего. Очень хотел попасть в TransferWise, у меня релевантный опыт к ним и там толковый тимлид, но они в Черкассах. Я предложил на испытательный срок поработать у них в Черкассах а потом на удалёнку только подъезжая на бэклог грумниг, но сказали так им не пойдёт.
* Джинни реально рулит — очень много отзывов пришло на моё резюме. В LinkedIn кроме спрамерш тоже нашлось несколько настоящих рекрутёрш. Из сайтов вакансий тоже только по ДОУ Работа прошёлся, несколько отличных вакансий было.
* Крупные аутсорсы — походу отстой. Из крупных только Люксофт ещё шевелится и работает.
Например ЕПАМ свои вакансии на ДОУ вообще не публикует, но я зашёл на их сайт нашёл таки открытые позиции и зааплаился на несколько на которые подхожу, ии… всё. Никакого ответа. Вообще у меня такое впечатление что в Епаме уволили весь HR отдел, а чтобы нанять новых нет эйчаров.
У Глобалоджика вакансий по джаве не было на сайте вообще, также у Инфопульс. У Сиклума было вакансий клёвых, но видать не заинтересовало моё резюме. Отписались только вчера, когда я уже офер принял. А ведь это всё лидеры в топах.
Люксофт не подкачал, две крутые позиции предложили, жаль моего уровня не хватило — там нужно было хорошо уметь многопоточность.
* Да, кстати к заголовку поста, синьёров спрашивают по сути тоже что и мидлов и джуниоров: Java Core, коллекции, мапинги в хибернейт, скоупы бинов в спринге, пару задачек на агрегацию SQL, но в добавок особенно уже начинают расспрашивать низкоуровневую жесть: про то как работает Garbage Collector, как исправлять проблемы на сервере через jconsole, и особенно жёстко Concurrency — что такое ThreadLocal, volatile. Проблема в том что конкаренси это такая жёсткая тема которую ну просто невозможно изучить не поработав на проекте с нею. Вопросы по алгоритмам почти всегда — на знания деревьев и их обход.
Ну и как всегда к реальной практике вопросы обычно отношения почти не имеют.
* Почти все взяли моду спрашивать логические задачки на собеседовании и давать тестовые задания. Причём если логические задачи ещё хоть как-то можно обосновать, то тестовые задания я вообще не понимаю зачем давать. Вот прошёл я отлично техническое интервью, ребятам явно понравился, да и я бы уже готов к ним идти, но нет — вот вам тестовое задание: напишите простую веб апликуху с импортом в БД из CSV файла.
А у меня через час после них следующее собеседование назначено, а на следующий день ещё три. Такую апликуху сделать — как два пальца, но блин это всё равно время часа на четыре минимум, за которые никто не заплатит. А когда ты почасово поработаешь на удалёнке то начинаешь особо ценить время. И особенно его начинаешь ценить когда вторую неделю не зарабатываешь а ходишь по собеседованиям.
И делать ну вот реально не хочется: задача не интересная, тебя по скайпу перебивают эйчары, и вообще лучше время потратить чтобы освежить знания про конкаренси чтобы завтра на собеседовании не краснеть. И даже примитивную программу писать всё таки долго: ты, например, можешь отлично шарить хибернейт, но тебе всё равно нужно будет потратить время чтобы его правильно подключить к проекту, потому что ты этого не делал никогда а работал на работе где уже готовое приложение было. Потом прописать мапниги, наколбасить тесты, побороть пару непонятных исключений из-за опечаток — вроде и фигня, а на каждом новом проекте съедает кучу времени.

И что этим тестовым заданием хотели посмотреть? Как я пишу код? Так для этого можно на гитхаб зайти посмотреть, я же его указал в резюме. Ну или прямо на собеседовнии можно простой код написать.
Узнать как я шарю техническую жесть и знания технологий? Ну так тут задача на один контролер с десятью строчками кода. Ну и опять таки — резюме, гитхаб, вопросы.
В другой компании дали обычную TDD кату пройти. Опять таки: ну и что по этой кате можно узнать? Шарю ли я ТДД? Ну шарю, это можно и вопросом выяснить. Может какую архитектуру я наваял в итоге? Так по ТДД архитектура всегда выходит не самая лучшая, зато рабочая. Это всегда так при разработке снизу вверх.
И да, тоже пять часов её втыкать не интересно.

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

А вот что мне реально понравилось и считаю хорошей практикой — это когда мне дали листинг кода и спросили какие ты тут проблемы видишь и как бы отрефакторил.
И тут да, сразу поехало: тут ненужный автобоксинг, тут дженерик бы дописать, вот это в метод заэкстрактить, тут в JDBC лучше сделать prepared statement и ещё забыли ресурс закрыть. 15 минут за которые интервьювер узнал про меня в разы больше чем за пятичасовое тестовое задание.
Когда в следующий раз буду сам собеседовать обязательно возьму эту практику.

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

Опять таки, мне сложно судить, но походу и хороших девелоперов маловато на рынке. На нескольких собеседованиях где я конкретно не тянул по опыту меня всё таки очень захотели. Подозреваю что причина в том что у меня из преимуществ инфраструктурный опыт наработанный самостоятельно: как настраивать сервера, CI, билды, правильно тестировать, и много ещё ботвы с которой на нормальных проектах разбираются девопсы, и да, походу самые лучшие уехали в Долину и прочую Ойропу. Те что остались стали архитекторами и меня теперь собеседуют. Ну и да, когда ты проходишь уже с десяток интервью то на вопросы отвечаешь сходу. И да, может это потому что если тебя уже пригласили на собеседование то уже заинтересованы именно в тебе.

Ну вообщем устроился я в неплохую вроде компанию, с офисом недалеко от дома, и хороша она тем что продуктовая, канбан, тдд и шведская — тайм шифт всего в час но главное что тимлид явно толковый, наверняка многому научусь от него.
Надеюсь сработаюсь.

Что спрашивать на собеседовании

2 Комментарии »

Ох, как же тяжело быть программистом

Расскажу я былину в назидание начинающим программистам.
На заре своей программисткой карьеры я узнал такую мудрость:

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

evil_programer
А всё потому что написанная однажды твоя программа будет ещё переписываться много раз. И скорее всего не тобою…
И я начал чётко следовать этому правилу и стараться писать код хорошо.
Время шло и я узнал следующую правду жизни:

Как бы ты не старался, тебе потом будет стыдно за этот код и даже будет хотеться переписать.

Чёрт побери, и ведь правда! Всем программистам стыдно.

Как же с этим жить? Но вот на одной конференции я узнал спасение:

Плохой программист пишет в день 200 строчек кода а хороший программист удаляет в день 200 строчек

И я стал наблюдать за хорошими программистами, подглядывать в монитор и смотреть на их работу в репозитории и понял что это тоже правда и узнал как они это делают.
Хороший программисты делают рефакторинг кода и используют возможности библиотек и компонентов.
Точно! Я тоже так буду делать а не мастерить велосипеды.

И вот я переколбасил код думая что я сделал «рефакторинг», ну ничего что без тестов, но работать должно. И вместо написания своего CSV парсера нашёл в интернете и подключил к проэкту какой-то чужой, который ещё и Excel файлы шарит парсить, и в БД сразу записывать и кофе варить и ракеты запускать.
Я удалил не 200 а 400 строк! Йуху! Какой же я крутой :-)

И в припрыжку понёс показывать это всё архитектору на ревью.
А он глянул и сразу дал мне по шапке: «А это что за библиотека? А ты уверен что в ней нет багов? А класс этот ты зачем поменял? А ты тесты написал? А ты уверен что после твоего рефакторинга оно будет работать как прежде?».
И рассказал мне программисткий анекдот:
Работает - не трогай

И ты так и продолжаешь работать на проекте постоянно дописывая костыли и накапливая технический долг.
И вот наступает такой момент когда прибегает к тебе проджект менеджер и говорит «там заказчику нужно срочно поменять стратегию начисления скидок к рождественским продажам. За сколько можешь сделать?».

А ты хрен его знает даже что отвечать — там такой код уже непонятный, всё в костылях, писался десятью индусами и те уже поувольнялись.
— Ну за два-четыре дня. Наверное.
— Отлично! Два дня, так и скажу заказчику.
И убежал.

И вот ты садишься разбираться как же там начисляются эти скидки, а там какая-то хрень, и ничего непонятно. И нет никаких тестов, поэтому как это работает непонятно и менять что-то страшно.
А были бы тесты, открыл бы их и почитал бы как спецификацию. Но их нет. И ты понимаешь что

Любой код без автотестов сразу становится legacy: никому непонятный, хрупкий и почти неизменяемый, и все уже через неделю забудут что он делает и как.

Посидел, поглядел в монитор часик.
Нет, всё равно непонятно. Как оно, блин, вообще работает? Я убил бы того кто это писал, вот бы узнать где он живёт… и бензопилой… или лучше в кислоте его…
Пойду кофе заварю.
Вернулся, посидел ещё часик.
Скучно. О! Новый имейл.
Потом ещё часик.
А что там в твитере пишут?
Потом ещё часик.
Зайду-ка я на хабру, может чё интересного почитать.
Потом ещё часик.
Так, ладно. Нифига не понятно, пора домой.

Следующий день проходит примерно также. И вот заходит к тебе проджект менеджер, а у тебя на весь монитор башорг:
— Нушотам, сделал?
— Та я это… там непонятно..
— Блин, ты же обещал за два дня сделать! А ты башорг читаешь!
— Ну… за два-четыре…
— Да продажи уже начнутся через два дня! Короче у тебя дедлайн до завтра. Иначе уволю нафиг, бездельника.

И ты понимаешь следующую инженерную мудрость: оценка сроков почти всегда ошибочна, поэтому всегда умножай сроки на три, потому что вероятность успеть имеет биномиальное распределение:

http://www.slideshare.net/Cartmendum/pmlabs09-part1

Но деваться некуда, и ты вливаешь в себя кучу кофе и сидишь допоздна на работе с красными глазами в глубоком дебаге, пытаясь найти то место где нужно поменять строчку и не приходя в сознание наконец-то меняешь её чтобы скидки считались по новому.

И всё? Вот это вот я три дня ковырялся чтобы одну строчку исправить? Блин, я программист а кода как-то и не пишу. И новая истина которая открылась тебе гласит:

Большую часть времени программист читает код, а не пишет.

Блин, это совсем не романтично :-(

Ну вообщем заказчик уже нервничает и ты сдаёшь программу. А твой QA на проекте тоже был занят и не успел протестировать твой код и так он и отправился в продакшен.

И тут, рождественская распродажа, заказчик сделал рассылку, запустил рекламу, и пользователи тысячами ломанулись на сайт покупать подарки близким и тут… баг! Они пытаются купить товар а им выдаётся ошибка. Они давай опять пробовать, обновляют страницу и снова ошибка.
И эта тысяча пользователей обновляющих страницу генерирует десятки тысяч запросов и сервер не выдерживает и вообще падает.
В техподдержке разрывается телефон, владелец сайта в бешенстве. А он, межу прочим, в 90х ларьки крышевал, а ты как раз хорошо влезешь багажник в его джипа. Ты этого можешь и не знать, а он об этом подумал проезжая мимо карьера.

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

А ошибка оказывается происходит когда пользователи цену указывают с центами. И вдруг ты понимаешь —
а в США десятичный разделитель не запятая, а точка! И ты вбивал $5,50 и у тебя работало, а американцы вбивают $5.50 и получают ошибку. Но ты об этом ну вообще даже не мог подумать, и отдал не до конца протестированный код и который ну просто обязательно и завалился. Это было неизбежно, потому что есть Закон Мерфи который гласит:

Если что-то сделано так что может поломаться, оно обязательно поломается

Засучив рукава ты фиксишь, отдаёшь тестировщику, он проверяет и говорит — а ты не учёл что пользователь цену может вбить вообще отрицательную. Ой блин, а ведь правда, так мы ещё и должны можем остаться им, и фиксишь и этот кейс.
Ты об этом даже не подумал а QA как раз о таких моментах и думает. Потому что ты в муках рожал этот код и поскорее хотел закрыть тикет в баг трекере, ты думаешь о решении задачи, а QA думает о том чтобы она работала верно. Поэтому ты чётко усваиваешь следующий горький урок:

Всегда твою работу должен тестировать другой человек, желательно специально этому обученный QA.

Но время идёт, потихоньку ты учишься делать рефакторинг правильно и быстро, средствами IDE, покрывая тестами, в заранее выпрошенное у заказчика время.
Но работа тебя постепенно перестаёт переть. Это уже совсем не тот драйв который ты испытывал когда писал Змейку на втором курсе.
Какое-то унылое ковыряние в XML конфигах, баг фиксинг, чтение документации, разговоры с коллегами.
А при этом прогресс не стоит на месте, и вот выходит новая версия библиотеки, где добавился новый функционал а старый будет удалён. И тебе нужно посидеть попробовать её, прочесть книжку, попробовать пописать код. Но это не в рабочее время, естественно.

Нужно бежать за прогрессом чтобы оставаться на месте

Как быть? После работы дома ещё начинаешь себе pet project, так, чисто для души.
Жена недовольна — муж приходит с работы и снова за компьютер и в наушники. Сначала бесится, а потом рожает тебе ребёнка чтобы ей скучно не было. Теперь дома детские визги вообще не посидеть кодить — и начинаешь засиживаться на работе до 11ти.
А что делать? Как-то же обучатся нужно.
И постепенно твоя производительность снижается и устанавливается на определённом уровне, и тебе открылась следующая истина:

все работники креативной специальности: маркетологи, художники, музыканты, программисты — никогда не могут работать больше, чем четыре часа в день.
© bobuk

Но вот случается чудо, и заказчику нужно написать новое приложение. У вас есть возможность написать проект самим с ноля! Не какого-то старого монстра фиксить костылями, а начать с чистого листа.
Тут вы сразу же восторженно рисуете UML диаграммы, схему БД и выбираете стект технологий: что там сейчас самое модное? MongoDB, AngularJs, Scala? Ну и конечно же сразу нужно всё писать для cloud!
Начали писать, всё круто, но тут заказчик начинает сразу вносить поправки в техническое задание, причём нужно опять успеть до дедлайна, архитектуру переделывать некогда и снова ваш код заростает костылями.
Как это не прискорбно, но следующее открытие:

Начали в стиле «Хай-тек». Продолжили в стиле «Пусть так». Закончили в стиле «Хрен с ним».
© Dmitriy Efimenko

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

Именно поэтому, вообщем-то, хороших программистов не так много. И именно поэтому им платят относительно неплохо (а на самом деле ещё и сильно недоплачивают).

Но однажды ты почувствуешь спокойствие и Силу Джедая. Как к этому прийти обязательно посмотри этот коротенький и чудный рассказа Андрея Солнцева:

UPD Похожая статья В поисках идеального программиста

8 Комментарии »

Говорящие и красночные логи FreeTTS Log4J Appender

Помню как в первый день на работе явистом, я с восторгом запускал огромное энтерпрайз приложение.
Сначала через Putty по SSH конектился к серваку под каким-то стрёмным юниксом, там стартовал кеш сервер, затем подключался к другому серверу где запускал уже бэкенд сервер и затем запускались вью сервера.
Всё это было для меня как запуск какого-то космического корабля: несколько этапов и куча мутного текста в логах, после чего 15 минут и ты на орбите и можно наконец открыть в броузере. Я восхищался крутизной этой системы и собой как её повелителем.

Собственно уже на следующий день меня это уже достало окончательно и я принялся искать пути как проверить свои изменения без полного передеплоя. Разобравшись и поняв что с этим монструозной легаси системой такое не прокатит я выработал традицию запускать систему и сразу же идти за кофе, или открывать хабру. Мда… И уже всё стартануло, но надо же дочитать срачи в каментах!
А потом ещё обнаружить что тупанул и забыл где-то в toString() поставить пробел и опять перезапускать перестиестивать :)

Вообщем, эффективность труда и удовольствие от кодинга неумолимо таяли. И я не единственный кто страдал от такой проблемы. Поэтому на многих проектах были свои поделки поверх ClassLoader для хот редеплоя кода. Одна компания даже на такой погремушке бизнес построила.

Сейчас, благодаря TDD, и модульной архитектуры у меня проект стартует уже не 15 минут, но всё равно несколько довольно мучительных минут в течении которых непонятно чем себя занять.
Хабру уже не почитаешь, разве что пару твитов. Я решил просто «откидываться на спинку кресла» и закрывать глаза чтобы отдохнули.
откиньтесь на спинку кресла
Но тут появилась проблема: сервер уже стартанул, но как это увидеть с закрытыми глазами? А если ещё на этапе компиляции произошла ошибка а я с закрытыми глазами ещё пару минут тупить буду?

И тогда я решил что нужно просто озвучивать процесс запуска. Для начала я дописал обычный beep(), но это костыль. Хочется слышать как приложение проходит разные стадии а не только финальный звоночек.
Поскольку звуки на все случаи жизни искать тоже не вариант, то я решил использовать синтезатор речи и подключить его в как обычный апендер логов. Благо это пару строчек кода.
Синтезатор речи для джавы, пускай и слегка заброшенный, но есть.
В результате представляю вам FreeTTS Log4J Appender. Прошу любить и форкать.
Как подключать описано в ридми, но если в двух словах то нужно подключить мой мавеновский репозиторий и прописать его депенденси.

Оставить комментарий »

Нужно ли указывать непрофильное образование в резюме?

Вопрос по поводу резюме. Я сейчас заканчиваю второе высшее, бакалавр, Computer Science… до этого я закончил английскую филологию :(
И у меня по этому поводу комплекс — я в резюме об этом нигде не указываю. Правильно ли я делаю?
Тебя бы отпугнуло такое резюме Java Junior, где в графе образование значится Иняз и Computer Science?

Ответил так:

  • Первое высшее обязательно указывай. Во первых, это твоё высшее, и это уже довольно круто и почётно. Далеко не каждый может его получить. Та даже не высшее — это твои знания, и их стыдится вообще нельзя.
  • Во вторых специальность крутая — англ филология, значит Инглишь шаришь или как минимум любишь.
  • В третьих — чтобы не было вопросов «а чем ты занимался всё это время?».
  • В четвёртых — есть компании которым именно такой человек может и нужен. Например Gramarly — они делают проверку орфографии для английского и им может нужен человек который поможет сделать структурный анализ текста на соответствие художественному или научно популярному стилю.

Хуже точно не будет, а плюс будет в любом случае.

Оставить комментарий »

kranonit S20 Django — легко, быстро, эффективно

stokito:

Ух ты, кранонит выходит из спячки!

Originally posted on #kranonit Клуб анонимных айтишников в Кривом Роге:

9646be688285186b8605df7ec308e29f

Легко, быстро, эффективно — эти слова в полной мере описывают самый популярный фреймворк для веб-приложений на языке Python. Отличная документация, быстрая скорость работы, удобная настройка и разработка приложений, гибкость инструментов и возможность наработки собственных стандартных фрагментов кода, которые затем могут применяться повторно… На этом преимущества Django не заканчиваются. 7 марта Сережа Бурма, наш давний друг, расскажет гораздо больше о самом фреймворке, его особенностях и преимуществах, покажет, как за пару часов можно создать сайт, его админку да и в целом как довести проект до ума. Не пропустите! Такой мастер-класс бывает не каждый день ;)
Место проведения неизменно — 322 ауд. пединститута (главный корпус, Гагарина, 54). Ждем вас в 10:00. Взнос на чай и печеньки — 15 грн.

View original

Оставить комментарий »

Как быстро можно стать Java Junior?

Максим Педич поделился опытом: для того чтобы изучить Джаву с нуля нужно пол года активного вкалывания.

Макс Криворучко дополнил

Чтобы стать программистом (читай освоить Java core) нужно пол года. Чтобы стать интересным для компаний программистом нужно знать кроме Java Core как минимум еще и тулы (maven/gradle, svn/git), jdbc, Servlet API, Spring (IoC). Было бы хорошо знать еще и html, sql, xml на базовом уровне.

В случае знания Java Core светить может интернатура,

во втотом случае — могут взять джуном.

Самое главное: по каждой теме иметь практику. И чем ее больше — тем лучше. Даже читая книгу, в которой примеры кода — нужно как обезьяна его перепечатать в IDE и запустить.

чтобы стать джуном нужно год-полтора

Оставить комментарий »

Отслеживать

Настройте получение новых записей по электронной почте.

Присоединиться к ещё 810 подписчикам