andkorol

Какие задачи нужно уметь решать на чистом JS, перед тем как переходить к изучению библиотек и фреймворков?

Кроме синтаксических конструкций, математических и логических выражений, нужно знать:

• Область видимости переменных
  
• Замыкания
  
• Объектно-ориентированное программирование, в частности наследование через прототипы
  
• Шаблон проектирования "модуль"
  
• Операции над DOM
  
• Понимание принципов событийно-ориентированного программирования
  

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

Важно - инструменты программиста JavaScript
У тебя должен быть удобный инструмент для разработки (IDE, Integrated Development Environment), чтобы он тебе подсвечивал код (syntax highlight) и подсказывал о синтаксических ошибках (syntax check), о формальных параметрах функций (type hinting), о стиле кодирования (code style), помогал писать код (live templates).
Ты должен знать, как отлаживать скрипты в популярных браузерах (Firebug, Chrome Developer Tools и другое). Что такое точки останова, как управлять исполнением во время останова, как посмотреть и поменять содержимое переменных, как настроить останов по условию.

Хотелось бы узнать что это за задачи(упомянутые вами 80%)

Реальные задачи джунов:

1. Возьми из сборника задач по javascript любой скрипт случайно и вслух расскажи, что он делает.
   Важно - читать и понимать чужой код намного важнее, чем писать свой. И на работе тебе это приддётся делать чаще, чем ты думаешь. Чтобы подключить к своему проекту чужую JS либу, нужно понимать что она делает, как она конфигурируется, как управлять её поведением. Скажу точно, что написать свой скрипт, который строит графики, намного сложнее, чем понять, как настраивается highcharts.
   
   
2. Напиши скрипт на JS, который в заданном тексте удалит один или два символа, выбранных случайно
   
   1. Усложнение: удалять можно только буквы в словах, а знаки пунктуации и цифры удалять нельзя
      
   2. Усложнение: принять, что этот текст является программной на Javascript, удалить одну-две команды JS, но только если они не в строковых литерах (break как команду удалить можно, а в строке "break my heart" нельзя)
      
   3. Усложнение: воспользуйся этим скриптом и "попорти" код какого-нибудь другого скрипта на Javascript, а потом отладь, найди ошибку и восстанови работоспособность
      
   Важно - этим обычно все и занимаются - ищут баги. Только в реальной жизни они и без этого скрипта появляются. И не по одному, а прям пачками.
   
   
3. На страницу HTML нужно встроить график курса доллара по отношению к рублю. Формат входного массива значений курса определи сам, исходя из своего скрипта для построения графиков.
   
   1. Усложнение: на одном графике должны быть два курса, по разным шкалам. Наприме, курс доллара к евро и курс юаня к рублю
      
   2. Усложнение: первоначально график вывести в детализации по месяцам, но чтобы можно было "приблизить" (drilldown) детализацию до дней
      
   3. Усложнение: первоначально график вывести текущем месяце, но чтобы можно было загрузить данные для предыдущего месяца без перезагрузки страницы (AJAX)
      
   
   
4. При клике по картинкам, вставленным в текст HTML, показывать всплывающее окно для просмотра увеличенной картинки.
   
   1. Усложнение: в всплывающем окне сделать навигацию по картинкам, вперёд/назад и к нужной картинке
      
   2. Усложнение: в всплывающем окне вместо картинки показать видео-ролик с Youtube
      
   3. Усложнение: в всплывающем окне показать текст HTML
      
   
   
5. По клику на кнопку "Click me" показать всплывающую форму.
   
   1. Усложнение: реализовать проверку данных на корректность перед отправкой формы (непустое значение, минимальное количество символов, максимальное количество символов, минимальное числовое значение, максимальное числовое значение)
      
   2. Усложнение: если в значении текстового поля встретилась гиперссылка, то считать её за 22 символа при любой длине этой ссылки (как в твитере)
      
   3. Усложнение: реализовать отправку формы на сервер через AJAX, без перезагрузки страницы
      
   4. Усложнение: саму форму в виде HTML загрузить с сервера через AJAX, в момент клика по кнопке "Click me", правила проверок данных должны как-нибудь "извлечься" из самой загруженной формы, например из аттрибутов полей ввода
      
   
   
6. К форме ввода данных на поле ввода даты "навешать" всплывающий календарь для выбора даты.
   
   1. Усложнение: сделать форму календаря мультиязычной. Хотя бы через настройки на том же JavaScript
      
   2. Усложнение: сделать так, чтобы с помощью календаря можно было выбрать диапазон дат, чтобы она была привязана к двум полям формы "дата начала" и "дата окончания", и чтобы значение в поле "дата начала" обязательно была меньше чем в поле "дата окончания"
      
   3. Усложнение: сделать так, чтобы с помощью в календаре можно было видно визуально этот диапазон
      
   4. Усложнение: диапазон может быть открытым, но не пустым, то есть пользователь должен задать хотя бы дату начала или дату окончания.
      
   
   
7. Сделать пред-просмотр веб-страницы HTML с разными темами. Тему страницы выбирать через селектор на javascript, а показывать в фрейме.
   
   1. Усложнение: сделать селектор "тип устройства", чтобы менять размер фрейма (например, "iPhone 5c 1136x640") и "чекбокс" для смены ориентации страницы "горизонтальная" или "вертикальная" (соответственно 1136x640 или 640x1136)
      
   2. Усложнение: в селекторе тем предусмотреть поиск тем по подстроке, и аналогично поиск устройств по части названия (авто-дополнение, auto-complete)
      
   3. Усложнение: тема страницы должна меняться без перезагрузки фрейма
      
   
   

Задачи повышенной сложности, исходя из личного интереса

1. Реализовать форму для многошагового мастера: форма должна состоять из нескольких страниц (шагов), пользователь может переключать страницы через какие-нибудь элементы управления "вперёд/назад" или "перейти на страницу".
   
   1. Усложнение: реализовать функциональную связь значений, когда некоторые данные зависят друг от друга (ввёл число в поле "количество" и в поле "сумма" значение пересчиталось)
      
   2. Усложение: доступность некоторых полей ввода должна зависеть от данных (например, если указал "есть личный самолёт", то значит можно ввести "марка самолёта")
      
   3. Усложение: видимость некоторых страниц должна зависеть от данных из предыдущих страниц (например, если указал "есть личный самолёт", значит появилась страница "ТТХ самолёта"; иначе страница должна скрыться)
      
   
   
2. Реализовать однопользовательскую браузерную игру "змейка", "тетрис", "найди пару"
   
3. Реализовать многопользовательскую браузерную игру "крестики-нолики", "морской бой" на два игрока в режиме "hot seat"
   
   1. Усложнение: два игрока на разных компьютерах, ходы передаются по websocket
      
   2. Усложнение: ограничение на ожидания окончания хода 15 секунд, по окончании ожидания автоматически делается случайный ход
      
   
   
4. Реализовать todo-list. Пользователь вводит список, затем он превращается в строки с "чек-боксами". Когда "чекбокс" включен, строка зачёркивается.
   
   1. Усложнение: пользователь может переименовывать, удалять, добавлять строки
      
   2. Усложнение: список хранить в localStorage браузера, чтобы при перезагрузке страницы он восстанавливался
      
   3. Усложнение: пользователь может иметь несколько независимых списков todo
      
   
   
5. Реализовать простой графический редактор. Пусть рисуется точка в месте, где пользователь кликнул.
   
   1. Усложнение: добавить переключатель режимов "точка"/"линия", в режиме "линия" рисуются линии между двумя последовательно кликнутыми точками
      
   2. Усложнение: можно менять толщину, цвет линий, размер точек
      
   3. Усложнение: последовательность кликов можно воспроизвести ещё раз с самого начала, равномерно или с реальной задержкой между кликами, с обычной скоростью или ускоренно
      
   4. Усложнение: можно выгрузить получившийся рисунок в формате PNG или SVG, причём SVG c анимацией воспроизведения
      
   
   

Можно использовать любую существующую библиотеку.
Например,
для построения графиков www.highcharts.com
для загрузки и передачи данных через AJAX: jquery.com + что-нибудь на сервере
для всплывающих диалогов с картиками, видео и формами: fancyapps.com/fancybox и https://jqueryui.com/dialog/
для валидации форм rickharrison.github.io/validate.js
для календаря https://jqueryui.com/datepicker/
для автодополнения https://jqueryui.com/autocomplete/
для передачи данных между несколькими пользователями socket.io или обычный AJAX

Привет, начал употреблять фасфуд, набрал 15 кило, теперь хожу в треник, так что фастфуд и прочие кафешки это не вариант, сейчас купил мультиварку с функцией скороварки (обязательно), просто закинул в нее нужные продукты по рецепту и ушел заниматься своими делами, очень здорово стала экономить время, всячески советую, удачи)

Закупаюсь 3 раза в неделю в большом супермаркете, т.к. если закупаться 1 раз в неделю (это всего 4 раза в месяц), продукты, что лежат в холодильнике, почти всегда отправляются в мусор, потому что они доставляют радость только первые дни после покупки, и всегда отдаешь предпочтение тем, что только купил.

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

За все время работы на oDesk, я для себя я выделил несколько важных моментов:
- мониторить проекты и отвечать в первые 10 минут после публикации
- быть уверенным в себе и показать клиенту что вы действительно сможете сделать данный проект(скинуть ссылки на ваши похожие проекты).
- сразу озвучить свою примерную оценку бюджета и времени исходя из доступной информации.
- полностью изучить job description и все прилагающиеся документы и показать клиенту что вы не просто отправили ему письмо, а действительно постарались разобраться с его проблемой.
- предложить свои идеи по решению проблемы уже в cover letter
- указать что вы готовы работать прозрачно и постоянными отчетами о прогрессе работы.
- задать вопросы которые вас инетересуют, это даст больше шансов что клиент ответит и вы сможете завязать разговор.
- очень важно писать на таком уровне английского чтобы вас сразу поняли. При чем отличные знания грамматика и орфографии хоть и являются плюсом, но совсем не обязательны. Главное чтобы клиент вас понимал.

Больше информации можно найти в моем блоге - jff.name/odesk-write-cover-letter

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

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

Описываю по себе:
1) Возможность создать свой собственный режим сна. Для меня вставать в 8-9 утра это настоящая боль. Уже год+ засыпаю между 3-4 часами ночи и просыпаюсь между 11-12. То есть абсолютно всегда сплю свою норму в 8 часов, для того чтобы чувствовать себя нормально и не пить никаких кофе.
2) Отсутствие временных/моральных/физических затрат на дорогу до работы. Конкретно мне жаловаться не приходилось, ибо первое место работы было в 10 минутах ходьбы от дома, но вот люди в больших городах от этого явно страдают.
3) Возможность жить и работать так, как это удобно ТЕБЕ. Вот сижу я днем, дописал только-что какой-то кусок проекта и смотрю в окно, а там солнышко светит и птички поют. Ну я беру и иду бегать на стадионе. И это все происходит в 2 часа дня. А что в офисе? Ходить проветривать мозги на улицу на официальных перерывах? А если заработался и пропустил перерыв, то что? Во многих компаниях придется сидеть дальше тупить.
4) Возможность работать тогда, когда это наиболее удобно и эффективно для тебя. Один из самых важных пунктов. В офисе пришел и сидишь 8-часовой рабочий день. И ты же не можешь подойти к начальнику и сказать, что у тебя сейчас мозги не работают, и тебе бы хотелось свалить домой вообще. Ну может 1-2 раза отпустят, а что делать если тебя в каждый второй день после обеда парализует на пару часов? Будешь в итоге сидеть и накручивать спагетти-код на вилку. А потом его рефакторить, матерясь. Мне вот например ночью нравится работать, но где вы видели офисы, в которых вам позволят одну половину дня работать там, а другую ночью дома?
5) Отсутствие привязанности к каким-то предпочтениям фирмы. Вот попали вы в веб-студию, делающую сайты на битриксе. И представим чисто теоретически что вам там платят нормальные деньги. А дальше что? Ну полгода вы попилите магазинчики. А потом еще полгода. И еще. Ну конечно не везде так уныло, но своих "особенностей" хватает во всех компаниях.
6) Отсутствие видимого потолка по заработку. В стандартной компании вас посадят на оклад, +небольшие премиальные если вся команда в сроки будет сдавать проект например и нарисуют вам роадмап, по которому вы будете строить планы на жизнь. Аля "через полгода сдам 7 проектов и меня повысят, увеличив зп на 15%". А потом в один прекрасный вечер после работы вы сядите изучать что-то интересное дома. И будете изучать недели-месяцы. И вот приходите вы однажды на работу, с кучей новых знаний, а у вас в голове стойкое ощущение того, что сейчас вы достойны не то что этой прибавки в +15%, а вы на все 30% тяните. Но вам никто этого не даст. Просто потому-что обычные офисы живут по другим правилам.

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

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

В общем лень мне в офис ходить, я спать с утра люблю.

Изучать на работе. Мне когда работа "позволяла" это делать - я и изучал и/или свой проект писал.
Да-да. Именно так. Совесть пусть идет в жопу.

Остальные советы - это бред школьников.
Если человек спрашивает, значит у него реально нет времени. Если есть семья - то подавно.
Если устает - то значит устает. Я помню, что значит тратить на дорогу 4 часа в день.
По вых лучше не работать слишком много - реально можно перегореть. Сам сгорал не один раз.
Оптимальное время для всего этого дела - будни.

Сначала нужно расписать функционал приложения по пунктам: составить список тех функций, которые будут у приложения. Далеко в будущее заходить не надо, так как планы могут поменяться.
Потом взять те пункты, без которых приложение не состоится, самые минимальные и базовые вещи, и сделать их. Например, для магазина это: витрина товаров, возможность заказать товар, указав адрес доставки. Корзина и регистрация на этом этапе не обязательны, так как магазин может работать и без них. А без витрины и возможности заказать товар не может. После реализации этих базовых функций уже можно накручивать функционал дальше.
Суть в том, что на каждом этапе у тебя должно быть законченное, рабочее приложение. Разница между этапами — степень проработки деталей функционала приложения. Это метод прогрессивного джипега :) Или agile.
Чтобы понять, с чего начать, нужно посмотреть на приложение глазами пользователя: пользователь заходит на сайт, видит витрину товаров, видит описание у товара, цену, другие параметры, кнопку купить и т. д. То есть нужно реализовывать сценарии поведения пользователя. Можно даже acceptance-тесты накатать — помогает собрать мысли.

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

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.

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

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

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

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

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

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

Решение конкретно твоей проблемы:
mysql_set_charset('utf8'); после коннекта
+
плюс таблицы должны иметь кодировку utf8
Подробнее: phpfaq.ru/charset

Разбор вопроса:

везде совет для записи в базу использовать mysql_real_escape_string(),

Это информация устарела и не соответствует действительности.
Единственно правильным вариантом добавления данных в запрос являются подготовленные выражения.

Как я понимаю необходимо обрабатывать текст вот так перед вставкой:

Неправильно понимаешь.
Перед вставкой текст обрабатывать не надо вообще никак.
Для корректной работы SQL, как я уже писал выше, должны использоваться подготовленные выражения.
HTML же к SQL не имеет ни малейшего отношения. и никакая HTML функция, разумеется, при сохранении в БД использоваться не должна.

К примеру "⇔" при записи в базу превращается в "?"

Вот с этого и надо было начинать. У тебя проблема с кодировками.