Я верю, не перевелись богатыри на земле русской! :)

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

Немного о семантических структурах

Не судите строго это мои тараканы веселятся в голове! :)

В этой статье я расскажу немного о том как я вижу семантическую структуру везде…

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

Шло время и все единицы информации накапливали в себе информации, и настал вновь этот переломный момент когда пришлось создавать новые части и связи. Шло время и информации становилось все больше и больше, и превращалось это в дерево информации. Дерево росло и расширялось, становясь все больше и больше. И тут дерево заметило что часть информации дублируется в разных частях и тут дерево решило избавляться от дублей создавая сеть. Так и появилась сеть. :)
А может все было наоборот? Сеть уже была а мы упрощали ее создавая простые понятные деревья доводя до одной ячейки информации? :)

Как знать все возможно в этом мире!

Что бы стать программистом нужно начать думать как программист

Что нужно, что бы стать программистом?

Программист это не набор знаний языков(а) программирования. Это свой образ мысли.  Так вот я выделил несколько характеристик программиста:

  1. Программист в первую очередь творец, создатель, художник
  2. Программист все автоматизирует, программист, который этого не делает — это кодер, тот кто тупо знает и пишет код
  3. Для программиста рекурсия это божество (на самом деле в рекурсии есть что то божественное ;))
  4. Каждый программист знает, что ошибки это плохо, нет ошибок вообще еще хуже. Это конечно шутка но в ней есть доля правды.
  5. Профессионализм измеряется не числом знаемых языков а скоростью изучения новых и понимания чужого кода.
  6. Программист знает все, но на своем языке.

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

И напоследок анекдот про программиста и чайник:

Есть задача: вскипятить чайник.
Условия: Чайник стоит на столе.
Решение: Включить плитку, взять чайник со стола, поставить на плитку, ожидать пока чайник вскипит.

Поменяем условия: Чайник стоит на подоконнике.
Решение программиста: Переставить чайник на стол, выполнить предыдущую процедуру.

Не так страшны велосипеды как ленивые программисты

Есть на свете миф «Хороший программист — ленивый программист». И я с полной уверенностью скажу что это всего лишь миф. Дело в том что программист или разработчик думают по особенному (TODO link). Зачастую из за этой особенности думать они попадают в «велосипедную ловушку».

Велосипедная ловушка — это место где разработчик боится или не хочет создать уже существующее решение, т.к. это решение уже существует. (Сам придумал :))

Но так ли опасны или страшны велосипеды? Давайте разберемся!

  1. Для начала все в мире уже изобретено. Мы только используем это изобретение и, так сказать, адаптируем к нашей обыденной жизни.
  2. Любое решение имеет свой срок жизни. Как бы универсальное оно ни было, все морально устаревает и требует модернизации или реинжиниринга. Всем известно что 3D движки к моменту релиза уже морально устарели.
  3. Даже сам велосипед претерпел множество изменений: От деревянного к велосипеду из карбона для велоспорта. И что в этом плохого?

Так вот ленивый программист — это плохой программист. Он не изобретет нового. А изобретение велосипеда в программировании неотъемлемая часть творения, создания принципиально нового.

Успешных вам творений!

Уровни Web-разработки | Как писать крутые веб-приложения

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

  • База данных
  • Ядро
  • Разметка и стили
  • Скрипты и приложения

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

  • База данных — в первую очередь осуществляет хранение и представление информации в удобном для программиста виде.
  • Ядро — посредник между базой данных и клиентом (в вебе это браузером далее по тексту буду использовать его) ядро это предназначено для обработки данных полученных из базы данных и отправка сформированных понятных браузеру данных.
  • Разметка и стили — получение данных от сервера (ядра) и представление их в удобном для пользователя виде.
  • Скрипты — основное назначение это динамика в Браузере. Изначально страницы в браузере были статичными, позднее появились скрипты в браузерах и это позволило динамично обрабатывать информацию. Пользуясь при этом возможностями разметки и стилизации.

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

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

Результат был множество разнообразных сайтов, CMS, проектов и всего подобного.

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

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

От автора:

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

Миграции базы данных MySQL, синхронизация, обновление, актуализация структуры и данных, версификация БД

Была у меня задача сделать миграцию базы данных… И я нашел достойное решение!

Немного о условиях для реализации:

  1. Один разработчик базы данных и серверной реализации продукта.
  2. 2 сервера: боевой и локальный
  3. Нужно генерировать патч файл для БД
  4. Для некоторых столбцов задавать ALTER TABLE CHANGE (rename column)

Вооружившись гуглом и яндексом я начал искать. Т.к. я пишу на PHP появлялось куча предложений использовать решение на PHP или ORM Doctrine или еще какая нибудь ересь. Т.к. уже изначально заложено что нет прямой жесткой связки между PHP и MySQL и меня не устраивал вариант на медленном PHP для реализации миграций. Были варианты написать самому и завязать это на Phing но это полный бред! Куча решений и не одно действительно полезно не было… Думал даже делать отслеживание изменений в PMA но это не удобно и долго.

Недолго думая я решил воспользоваться MySQL Work Bench!

Это оказалось моим спасением!

Во первых: это удобная среда для работы с БД MySQL

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

В третьих в WorkBench много различных средств для миграции баз данных. Бинго!

Вот оно вот то что я искал! Никаких велосипедов никаких костылей только мануал, ПО и база данных. Хочу отметить что не все в мануале есть и некоторые особенности или нюансы нужно самому ощутить (как это было со мной).

Мне нужно было сделать sql скрипт который пропатчит базу данных версии N до версии M. Но WorkBench Упорно не хотел делать ALTER TABLE CHANGE вместо ALTER TABLE DROP ADD. Как оказалось я не тот пункт выбрал в меню. Теперь я легко могу делать эти патчи для баз данных.

Кое какая приятная особенность…

Помимо того что можно делать делать скрипты можно осуществлять «слияние» баз данных. Т.е. Если в сравниваемой базе данных появилось появились обновления можно сделать патч и в обратном направлении. =)

P.S. Позднее я опубликую tutorial

Интернет-магазин

1Сейчас речь пойдет о интернет магазинах. Нет не те которые делаются за 20 минут с помощью готовой CMS, или посадочные страницы с 3-мя товарами и формой обратной связи. Я расскажу как можно сделать что-бы Вы контролировали все что происходит в интернет-магазине и в обычном магазине.

Есть компания «Подарки от Пупкина», которая, как видно из названия, занимается продажей подарков. Уже есть интернет магазин, множество товаров, постоянный поток заказов, регулярное обновление ассортимента, и пара отделов продаж (магазинов) по городу. Читать далее Интернет-магазин

Приложения для бизнеса. Или бизнес в «облаках»

Для чего нужны эти приложения? Как и любое приложение оно автоматизирует и упрощает процессы в Вашем бизнесе. Существует множество разных решений от простых до сложных, от узко направленных до сложных многоуровневых структур, дорогие и свободные. «И какой же вариант выбрать?» спросите Вы. Я вам отвечу но чуть позже, сначала расскажу про проблему большинства готовых решений. Читать далее Приложения для бизнеса. Или бизнес в «облаках»

Создание и разработка сайтов

Все хватит быть наемником. Так что у меня есть команда есть офис есть железо! И теперь мы новой командой сделаем революцию в сайтостроении! Чем же мы занимаемся?

  • Созданием сайтов и лэндингов
  • Разработкой веб-приложений 
  • UX-дизайном
  • A/B тестированием
  • Интернет маркетингом

Вот именно этим мы занимаемся! Да много кто этим занимается! Но именно мы занимаемся правильным созданием сайтов, и так же у нас есть масса плюсов и преимуществ:

Читать далее Создание и разработка сайтов

Проектирование.

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

Мир сложная штука и как не пытайся универсализировать это не получится не имея за плечами гигантского опыта решения всех задач. Что же на самом деле стоит делать? Пытаться универсализировать? Нет ни в коем случае. Это ни к чему хорошему ни приведет. Почему? Да потому что универсальное решение не получит нужной отдачи в отличие от частного. Самый прекрасный вариант это решить конкретную задачу. Как можно это сделать?

Читать далее Проектирование.