Какими MySQL менеджером на Ubuntu вы пользуетесь?

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

Сколько примерно стоит программирование сайта?

Дмитрий Энтелис: ну я говорю про топовых чуваков из пало альто с которыми приходилось общаться, есть и на Украине парочка чуваков, но там специфика.... В основном же мои знакомые берут по $40-$50 и довольны жизнью.

Как определиться с фреймворком?

Dmitrii Solovev: нууу не совсем пожалуй, в той части где вы говорите про толщину бэкэндов и фронтэндов.

Админка, где сервер генерирует формы и прочее обладает весьма скудным фронтэндом. Вы можете вообще без js все сделать и все будет работать. Если брать SPA то на сервере API а весь UI на клиенте.

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

В чем ошибка в php?

не про dependency injection а про dependency inversion. Dependency injection это лишь один из вариантов как управлять зависимостями.

Сколько слотов RUST можно разместить на 4GB ОЗУ?

Владимир Мусихин: ну как бы да, или чатик найдите фанатов вашей игрули...

Как определиться с фреймворком?

HoHsi: ну и да, "карта" это зовется mind maps. Удобная штука для визуализации информации.

Какими MySQL менеджером на Ubuntu вы пользуетесь?

AVKor: ну у меня это в терминале... хотел как-то подверкнуть "консольность"...

Как определиться с фреймворком?

HoHsi: нет, под web интерфейсом я подразумевал именно интерфейс по которому клиент общается с сервером. Обычно это HTTP запросы и HTML или JSON в ответ. Так же связанное с этим необходимость валидации данных, маршрутизация и т.д. К бизнес логике приложения это имеет весьма и весьма поверхностное отношение.

Ну и да, angular2 будет поддерживать server-side рендринг, если что. Так что "серверный angular" это не так уж и странно, просто заменить на бэкэнде базу данных на rest api и получится именно это, серверный angular, view прослойка, service-layer прослойка и контроллеры с маршрутизацией.

Как определиться с фреймворком?

Dmitrii Solovev: почитайте на вики про клиент-серверную архитектуру.

Почитали? Далее... у нас есть две типичные ситуации:

- обычные сайтики, как например тостер, где сервер отвечает за формирование интерфейса пользователя (html) и отдает его на клиент. в этом случае на клиенте практически нет бизнес логики, только UI составляющая. Например когда вы добавляете комментарий тут, срабатывает ajax запрос на сервер, страница не перезагружается, но это просто улучшение UX. То есть у нас тут ситуация с толстым сервером и тонким клиентом, так как часть ответственности клиента ложится на сервер.

- single page приложения, например google music или яндекс музыка, или любое другое сложное приложение. В этом случае у нас сервер ничего не знает о клиенте, а клиент ничего не знает о сервере кроме того, что тот предоставляем ему какой-то интерфейс (как правило поверх HTTP) для работы с оным. То есть каждое действие обрабатывается javascript-ом и что бы достать/сохранить данные шлет http запросы на сервер, но все это может происходить не видимо для пользователя.

так вот, возвращаясь к фреймворкам. Если мы берем приложение, то у него есть та часть которая общается с клиентом через web - его WEB интерфейс. В первом случае у нас это будут шаблонизаторы, формы и прочая чушь. Во втором это будут какие-то HTTP API, например, выплевывающие JSON, который уже обрабатывается на клиенте как ему там хочется. В этом случае на сервере для реализации WEB интерфейса применяют сериализаторы и прочее.

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

Еще может быть CLI интерфейс (командная строка), или например интерфейс для работы с очередями... бизнес логику все эти интерфейсы будут запускать одну и туже а ей, бизнес логике, глубого плевать каким образом клиент попросил нас что-то сделать. Запросил он страничку, сделал HTTP запрос или же инициировал цепочку команд... у нас будет какой-то слой который все это обработает, бизнес логика обычно не зависит от этого всего, ей побоку. Потому то и важно что бы бизнес логика была минимально завязана на фреймворк (чего обычно непроисходит, люди мнят фреймворки самым главным в приложении, как когда-то - базу данных).

По сути все эти задачи весьма стандартные и для их реализации пилить свои велосипеды людям надоело уже лет 20 как. В итоге пришли к фреймворкам, которые содержат решения большинства основных задач WEB разработчика. И эти backend-фреймворки обычно занимаются только решением общих проблем связанных с интеграцией приложения с WEB (ну еще есть ORM но это уже чуть другая история).

Но это все относительно задачь бэкэнда. Для фронтэнда же есть интересные особенности. В частности, в большинстве случаев за HTML отвечает сервер, а не клиент. То есть нам выплевывают кусок HTML с сервера а мы уже подключаем скрипты и прочее. В этом случае ни о каких фреймворках говорить особо не приходится, нам он не нужен что бы подключить какой-нибудь слайдер на jQuery. А с учетом того что скоро придут web-компоненты, все будет еще проще.

Но WEB развивался, требования пользователей росли. Скажем тут на тостере есть пара мелочей облегчающих жизнь, например добавление комментариев без перезагрузки страниц. Это то место, где чуть чуть бизнес логики вытекло на клиент, мы можем создать комментарий и сделать его отображение целиком на клиенте, общаясь с сервером через HTTP интерфейс и забрав у него данные в JSON формате, можем просто попросить что-то сделать и вставить HTML присланный сервером... тут короче вариантов масса. Тут уже в зависимости от задачи приходят на помощь различные библиотеки (заметте, пока не фреймворки), аля knockoutjs, understore, reactjs и т.д.

И вот мы дошли до полноценных приложений, которые целиком рендрятся на клиенте (мы сейчас не будем говорить о оптимизация аля server-side рендринг и т.д.), и сервер о клиенте не знает ровным счетом ничего. В этом случае помимо того что нам надо работать с UI (DOM), и мутить примитивную бизнес логику, нам еще нужна определенная инфраструктура для того что бы не превратить все в ад. Задача весьма себе обычная, реализовать структуру. Скажем angular предоставляет вам MVC подход (как впрочем и ember и react и т.д.), когда все разбито на малюсенькие UI компоненты со своей моделью, представлением и контроллером.

То есть у нас на клиенте появляется необходимость маршрутизации состояний, управление бизнес логикой, HTTP запросами (что-то посложнее $.ajax), очередями задачь и т.д. И тут на помощь приходят фреймворки, так как, как мы уже выяснили ранее, писать велосипеды это весело а вот поддерживать их в одиночку не особо.

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

- модульность, разбиение на отдельные компоненты
- отказ от двустороннего датабиндинга как идеи, данные должны идти только в одну сторону.
- абстракция от DOM (virtual-dom в reactjs), позволяющая ускорить тестирование, организовать server-side рендринг и прочие оптимизации.
- изоляция и web-компоненты

Пока отстает только Angular, но уже зимой вроде как релизится Angular2 который соответствует всем перечисленным пунктам. И когда выйдет Angular2, то идеологически различий между этими фреймворками не останется, в общем и целом все будет одним и тем же, различия будут только в реализации этих идей, и тут уже все субъективно. Мне вот с идеологической точки зрения нравится react но его инфраструктура убога, как-будто рубисты понабежали.

Словом... что бы не заплутать в этом море, просто стоит перестать зацикливаться на том что каждую неделю выходит по фреймворку и све такое. Во фронтэнд мире есть 3 основных лидера, которые идут к примерно одному и тому же, что говорит о верности направления развития. В бэкэнд мире разница между фреймворками только в количестве предоставляемых абстракций и ORM (извечный холивар active record vs data mapper). Все... больше различий нет. Со временем вы увидите общую картину и успокоитесь.

Как определиться с фреймворком?

HoHsi: нет не так.

Почему для проверки на пустую строковую переменную не используют empty()?

Дмитрий: ну тогда было бы неплохо рассказать чем вариант strlen/count хуже проверки наличия первого символа (ну мол... то что в первом случае проверка на пустоту будет занимать O(N) а во втором O(1)).

Как реализуют мега меню на php?

Слишком общий вопрос.

Почему для проверки на пустую строковую переменную не используют empty()?

Дмитрий: почему бы не делать нормально,$string === ''

Каким тегом можно заменить div class="main" в html 5?

добавлять свои элементы конечно можно, но тогда следует еще добавить "семантики" для роботов через WAI-ARIA

Какой js-фреймворк больше всего подходит для использования вместе с Ruby on Rails?

упс, не то.... ну то есть то но старая версия.

https://www.youtube.com/watch?v=0oGpWmS0aYQ

Какой js-фреймворк больше всего подходит для использования вместе с Ruby on Rails?

Голова есть не у всех к сожалению, да и фреймворки норм, главное знать их место в приложении. На эту тему есть клевая презенташка дяди боба:

https://www.youtube.com/watch?v=WpkDN78P884

Какой js-фреймворк больше всего подходит для использования вместе с Ruby on Rails?

eldar_web: оптимально бывает только под задачу. RoR это так же инструмент, который решает весьма себе скромную задачу - упрощает работу с web. На фронтэнд оно влиять вообще никак не должно.

Какой js-фреймворк больше всего подходит для использования вместе с Ruby on Rails?

eldar_web: я к тому что фронтэнд от бэкэнда фреймворка зависить не особо должен. В контексте SPA - бэкэнд это чисто апишка и все. В контексте "не SPA" - фронтэнд всеравно лежит как-то отдельно, ему важно только DOM и все такое.

Какие преимущества использования Webpack + Gulp?

просто на всякий случай оставлю тут пример использования Array.find который будет запускаться на IE9+ (на счет восьмерки не скажу, не проверял, но вроде полифил поддерживает).

import 'core-js/fn/array/find'; // подключаем из всего жирного полифила только Array.prototype.find

export default class SomeStuffManager{
    // ...
    getSomeStuff(id) {
        return this.when(this.data).then((data) => data.find((item) => item.id === id ));
    }
}

Какие преимущества использования Webpack + Gulp?

DarthJS: и? babel транспайлит все в es5, есть core.js из которого можно подключать только те полифилы которые нужны... словом никаких проблем с пользователями IE нет.