egorinsk

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

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

> Я работаю над php-проектом, который лежит у меня на сервере, доступ к которому по FTP-протоколу

Неудобно же, тормоза, Ide тормозит, синхронизация тормозит, все тормозит. Зачем так жить?

> А если использовать GIT (из того что я читал) все исправления нужно проверять локально.

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

Джеф Раскин, «Интерфейс», книга с ручкой управления кораблем на обложке.

> Я вам задачу выполню, а после меня хоть потоп.

Возможно, в большинстве случаев это и требуется. Заказчик хочет исправить баг A и добавить фичу B, а не устраивать дорогой и долгий рефакторинг.

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

> + ко всему меня еще смущает работа с файлами тем что это похоже на «интеграционный» тип тестирования, а этим не должен заниматься юнит-тест.

Юнит-тесту никто не запрещает прочитать файл в память до тестирования и отдавать тестируемому коду уже набор байт из памяти или что он там принимает на вход. Если ваш код требует на вход объект StreamPtr_t (какое странное название), то сделайте специально для тестов простейший MemoryStreamReader на 20 строчек.

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

А специально превращать файлы в портянки вроде "\xff" смахивает на извращение.

> Сниффер корпоративный

Желаю вам благополучно провалиться с этой бессмысленной затеей.

> Это не спам, а рассылки по информ агентствам.

А неужели нельзя переслыать информацию нормально, электронной почтой?

Плюс: скорость, простота и дешевизна разработки, легко найти исполнителей

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

Если речь идет о системах покупки рекламы вроде Google AdWords, там вроде рекламщики могут открыть гостевой аккаунт, дающий доступ на чтение.

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

20 лет опыта ничего не значат. Может этот человек 20 лет примитивные формы на 1С, дельфи и вижуал бейсике клепал, а молодой человек знает linux, C++, Руби и Хаскелл.

Если бы Стив Джобс и Билл Гейтс слушали «стариков» из IBM, вместо айфонов мы бы сегодня покупали громоздкие уродливые мейнфреймы с терминалами на печатающей машинке.

А вы попробуйте микрофреймворк вроде Slim. Он изучается за час максимум, мне, правда он не нравится, я бы лучше свой написал, но тем не менее, он очень прост и много времени на него не уйдет.

Для шаблонов стоит использовать нативный PHP.

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

На русском хороших материалов, увы, мало. Вот что надо изучить для веб-разработки:

— HTML, CSS, верстка, позиционирование и флоаты есть тут: htmlbook.ru/ softwaremaniacs.org/blog/category/primer/ chikuyonok.ru/
— Круглые кголки. тени, градиенты, трансформации и анимации CSS3
— Нарезка дизайна, основы фотошоп
— Основы дизайна и типографики
— Javascript: learn.javascript.ru/
— DOM интерфейсы: не знаю где, наверно в MDN (Mozilla Developer Network) можно почитать
— Таблицы совместимости браузеров: www.quirksmode.org/compatibility.html caniuse.com/
— Изучить какой-нибудь серверный ЯП
— Изучить базы данных: MySQL или Postgres или еще какую-то
— NoSQL: Mongo, Memcache
— Изучить ООП и MVC
— Паттерны разработки корпоративных приложений (есть книга от Мартина Фаулера)
— Особенности хайлоад приложений

Кто-то вам скажет, что все это необязательно изучать, что можно взять jQuery и Bootstrap, или поставить вордпресс с готовыми темами, в интернете полно примеров и статей, не слушайте его — с таким подходом вы научитесь лишь копировать увиденный где-то код и устанавливать плагины, а сами создать ничего не сможете. Все эти туториалы годятся только для воспитания обезянок, делающих потом сайты за еду на Друпале с украденным дизайном.

Если вы знаете английский, все гораздо лучше. Вот статья с Хабра с кучей туториалов: habrahabr.ru/post/156241/

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

Если тут не ответят, вам стоит написать прямо в mailing list этого компилятора, там-то точно должны знать.

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

Вы, прежде чем жаловаться на хабр, Касперскому писали? Там вполне успешно исправляют ложные срабатывания.

Не верю в чудеса и неожиданности.

Зато верю в то, что чем строже и больше различных проверок ввести, тем больше ошибок выскочит. Для этого:

1) ставлю error_reporting в -1 (показывать абсолютно все ошибки, включая всякие deprecated и strict standarts)
2) Иногда делаю код, преобразующий любую малейшую ошибку в исключение, валящее всю программу (в не-PHP языках это часто по умолчанию так и есть, и это правильно)
3) указываю type hints — если в функцию должен придти массив или объект определенного класса, то так и пишу
4) Ставлю assert() массово. Если переданный в функцию массив не должен быть пуст, а другая переменная не может быть отрицательной, проверяю это
5) Не использую @ и не исправляю ошибки, пока не пойму причину (так как реальная ошибка может быть в вызывающем коде)
6) В штуках, которые принимают плейсхолдеры, всегда проверяю соответствие числа плейсхолдеров и переданных данных
7) Жалею, что в PHP нет (или уже есть?) type hints для скалярных типов

> При правильном проектировании на самом деле часто бывает, что оно работает, и ты не понимаешь почему, и это нормально…

Нет, не бывает. Вы просто плохо разбираетесь в коде или особенностях языка.

На низком уровне программа, например, на языке Си, компилируется в ассемблерный код, у каждого процессора он свой. Самый популярный процессор — Intel x86, потому советую книги по работе процессора и ассемблеру Intel x86, регистры там, команды, и все такое. Правда, какую именно книгу посоветовать, не знаю.

Волшебные методы — зло. Человек, которому придется отлаживать ваш код, потом вас заживо на кладбище закопает.

Стоит ли кешировать простые выборки (по id) — спорный вопрос, для ненагруженных проектов — не стоит. Кешировать стоит сложные выборки, и в некоторых случаях, куски HTML.

Я когда-то думал над подобным способом для поиска слов с опечатками. Одним хешем тут точно не обойтись, и вот почему. Допустим (упростим задачу), все слова имеют одинаковую длину, например, 4 символа, мы хотим, чтобы у слов, различающихся 1 буквой, был одинаковый хеш. Тогда слова abcd и abce имеют одинаковый хеш, слова abcd и zbcd имеют одинаковый хеш… в итоге, все слова будут иметь один и тот же хеш.

Потому, одним хешем тут не обойтись. Нужно как минимум, несколько.

Например, хеш для всех букв, кроме первой. Хеш для всех, кроме второй, и т.д. Тогда у различающихся 1 буквой слов будут 2 совпадающих хеша.

Или другой подход — разбиение слов на триграммы и поиск по ним. У похожих слов большинство триграмм будет одинаковыми.