latteo

Откройте chrome://flags/ и ищите по "вкладки". Там есть "Автоматически удалять содержимое вкладок" и "Автоматически перезагружать только активные вкладки"

Проверять данные в каждом методе - это вполне отличная практика, по сути это соблюдение интерфейса метода.
Но возвращать при этом null/false - практика хреновая, если ваш метод на вход требует int, а получил array - надо бросать исключение. Так вы будете знать, что внешний код, который использует ваш метод работает не корректно.

Для объектов настоятельно рекомендую использовать type hinting:

public function test(MyObject $object, $id)
{
    if (!is_int($id)) {
        throw new \InvalidArgumentException('Argument "id" must be int');
    } elseif ($id < 0) {
        throw new \InvalidArgumentException('Argument "id" must be positive');
    }
...

Если пишете на семерке, то и для скаляров и на вывод - тоже стоит указывать type hinting. Правда с выводом не всегда это можно делать, например возврата null, или что-то еще.

public function checkPositive(int $intData): bool

Для сокращения проверок можете мой пакет заюзать https://packagist.org/packages/ko-ko-ko/assert, он спроектирован под максимальную производительность и использование в каждом методе.

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?

Да. За счет этого вы выигрываете в безопасности, надежности и времени поиска багов.

1. вместо /v1.0/ используйте теги гита
2. test | tests | ... - обычно это каталог для авто тестов
3. build | release | ... - это каталоги для собранных (релизных) файлов, тот же jquery.min.js например
4. external | vendor | ... - каталоги с внешними зависимостями текущего проекта
5. src | lib | ... - сам код проекта
6. bin - каталог с исполняемыми файлами для проекта
7. var | tmp | ... - каталог для временных файлов
8. Makefile - настройка для консольной утилиты make
9. bower.json - зависимости bower
10. package.json - зависимости npm
...

Видите ли, сейчас одно-файловые скрипты особо никто не пишет (не берем в расчет тривиальные на полторы строки).

зависит от задания, но лично я был бы рад перед собеседованием что бы была возможность глянуть на код кандидата (именно по этому меня расстраивают пустые профайлы на гитхабах и т.д.), это сразу позволяет понять ход мысли разработчика, его слабые места, а далее уже предметно говорить. Ибо в теории все все знают и понимают, а на практике оказывается что "все это только для собеседований".

С таким количеством пользователей можно и актуальный список улиц поддерживать на основе пользовательского фидбека.

Свои права на домены и публичные аккаунты (которые могут быть использованы для продвижения товара/услуги или для массового распространения позитивной/негативной информации о товаре/услуге/компании) могут предъявлять только владельцы прав на торговую марку (trade mark). Кто первым зарегистрировал торговую марку, тот и может заявлять права на все домены и публичные аккаунты, созвучные ей. Сам факт владения доменом, не дает права претендовать на все публичные аккаунты с созвучными именами.

P.S.: Думаю, тег Юриспруденция будет уместен для подобного рода юридических вопросов.

Вот Вам конфиги на все случаи жизни. :)
Практически в любом есть подобное описание, как настроить связку.

https://github.com/elasticweb/nginx-configs

1. IDE
2. xdebug
3. git
4. composer
5.bower
6.npm/bower
6. less/stulys/sass
7. grunt/gulp/webpack
8. apache/nginx
9. apc/opcache/memcache/varnish etc
10. bootstrap
11. VIM!!!!!!!!!
12. English!!!!!!!!!!
13. Все дырки через границу
14. Умение не читать ИТ литературу русских программистов за исключением Макарова, Индутного
15. Ненавидеть Попова

Ну я вроде подразобрался, но решения пока окончательного не нашел - да, апи есть, оно описано в доке на sdk, которое можно скачать отсюда, там в docs всё написано на первых страницах, есть пара примеров на java и python. Примерно выглядит всё так - есть api, доступное через сеть (или "как бы через сеть", localhost) и есть api, построенное как com - т.е. полностью локальное. Само API похоже на winapi - там есть всё, что нужно, дока по классам занимает около 300стр. Сам sdk написан на си\с++ , также есть "клей" для java и python. Для вэб версии вроде еще .net и php. Если вас интересуют другие языки - используйте либу в вашем любимом *language_name* которая сгенерит классы или другую обёртку на основе имеющегося WSDL (приложен к sdk). Вот с последним пока не разобрался.

Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

Давайте потренируемся:

• Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
  
• Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
  
• Что лучше: запущенный проект c jQuery или не запущенный без jQuery?
  

Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

Промежуточные дедлайны помогают успеть к последнему. Старайтесь сначала реализовать основную функциональность, а потом дополнительную. Если не успеете к дедлайну доделать дополнительное — сначала запустите основное, а потом видно будет, надо ли вообще доделывать дополнительное.

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

Удачи!

Данные надо проверять там, где они есть (гуглить "GRASP информационный эксперт").

В вашем случае мы говорим о "входящих данных". В контексте вопроса стало быть мы говорим о контроллере. Для модели данные тоже будут "входящими" но это уже будут данные в формате модели (например вместо строки готовый DateTime объект и т.д.)

Модель же не должна входить в "невалидное состояние" за счет бизнес правил и т.д (банально не должно быть возможности вызвать какой-то метод и сломать целостность состояния модели). А стало быть валидировать ее нет смысла.

Есть несколько вариантов вашего дальнейшего развития:

1. Если вы готовы "тренироваться на кошках", смело идите (вернее, записывайтесь) на курсы Software Testing (у них еще полезный форум). Там есть разные варианты, основы вам дадут и это будет крепкая база по небольшой цене (только не выбирайте ускоренный курс, лучше возьмите простой базовый). Перед этим можно заправиться онлайн-курсом Савина и курсом от Mail.ru (про него писали выше). Есть еще бесплатный вводный курс на Udacity.

2. Пойти на стажировку/обучение при крупной IT-компании (так училась я сама). Эти тренинги проводят Epam, ITransition, Veeam и другие. Ищите на хэдхантере по словам "QA/тестировщик/специалист по тестированию", затем выбирайте графу "без опыта". В Питере, кажется, есть несколько открытых позиций. Требуется знание логики и базовое понимание SQL. Кое-где - ООП (это уже зависит от компании и направления). Если указано, что ищут выпускников, а вы уже давно не выпускник, всё равно пишите: мотивацию ценят в первую очередь.

То, что очень сложно понять, не имея опыта, но можно предположить, зная себя и свои способности: решите, каким тестированием вы хотите заниматься.
- Веб-приложения, сайты и т.п.? Продолжайте зубрить Html/CSS/SQL, попробуйте поверстать. Без этих знаний попасть на джуниорскую должность тяжело - конкуренция высока.
- Функциональное - тот же SQL, администрирование (учите запросы в комстроке), язык (лучше Python или Java).
- Плюс, спросите себя, в какой сфере хотите работать. Если игровым тестировщиком, будет проще: на позицию джуна попасть легче, но нужен большой игровой опыт. Кроме того, есть мобильное тестирование, тестирование графического контента и артов и т.д. Подумайте, в чем вы сильны.

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

Подумайте над своим резюме и сопроводительным письмом - в 80% именно они решают, позвонят вам или нет.
Удачи)