Что ж вы так поздно анонс выложили. Узнал о мероприятии постфактум.
Можно ли как-то попасть в списки тех, кого будут заранее (недели за две хотя бы) уведомлять о Tizen-мероприятиях в России?
Новая эпоха наступит тогда, когда появятся и будут работать новые бизнес-модели, делающие децентрализованные сервисы финансово выгодным вложением.
Сегодня основой успешного бизнеса является монополия: сделай самый лучший сервис в какой-то нише, собери на своих серверах миллионы пользователей, и снимай сливки. Если же ты делаешь децентрализованный сервис, то копию твоего сервиса может поднять кто угодно, у тебя нет монополии, ты не можешь зарабатывать за счёт базы пользователей.
Все идеи того, как должны быть устроены децентрализованные социальные сети и другие сервисы, — эти идеи уже проработаны и обдуманы тысячами учёных и энтузиастов по всему миру. Но на разработку самого ПО, реализующего их, на описание протоколов и стандартов нужно много времени, а значит — денег. А денег на это никто не даст, потому что децентрализация противоречит сегодняшним моделям бизнеса. Также децентрализация является страшным сном для спецслужб и пугает государства, поэтому финансирования из бюджетов тоже ждать не приходится.
Одна из возможных моделей — краудфандинг. Но даже те, кто затеят такой проект, должны быть готовы на то, что это не станет их бизнесом и не сделает их богатыми. Максимум — даст среднюю по рынку зарплату на неопределённый период.
Обычно если стул высокий, то он барный, то есть не для долгого сидения в течение дня.
Хотелось бы типа такого, но с возможность подниматься на пол метра ))
Спасибо за картинку.
А что, если стол изначально сделать только под вариант стоя, а когда хочется посидеть — садиться на высокий стул типа барного.
То есть почему стул обязательно должен быть низким?
Про фреймворк я говорю в том смысле, что обычно в него включается комплект хелпперов, которые используются в явном виде и выполняют все те функции, о которых идёт речь, тогда и только тогда, когда и где они нужны.
Но вот тут уже пошла вкусовщина, так что предлагаю на этом остановиться.
Спасибо за мнение.
Это всего лишь термины и абстракции. В различных фреймворках они реализованы разными путями, но присутствуют.
В том же «Битриксе» есть те же редактируемые области в шаблоне и шаблоны компонентов, которые вполне себе наследуются внутри сайта/шаблона сайта/шаблона компонента/директории/страницы.
> Это проекты, над которыми работают параллельно несколько людей. В том числе и с шаблоном.
Шаблон позволяет разделять подготовку и отображение данных.
Разделить данные и отображение позволяет модель MVC. Это делается на уровне архитектуры проекта. Например, файлы шаблонов лежат в отдельной директории.
А совместная работа достигается с помощью систем контроля версий. При чём тут вообще шаблонизаторы?
> Язык шаблонизатора имеет упрощенный синтаксис, поэтому ему гораздо проще научить новичка.
Простейшие конструкции и в PHP вовсе не сложны.
А новичёк потом вырастет и всё равно будет вынужден либо выучить PHP, либо уйти в своей специализации от кодинга под шаблонизатор.
Хотя изменение формата передачи данных — это следствие неудачного решения на каком-то этапе.
Да и вообще должно быть единообразие: либо массивы, либо объекты.
А перед выводом в шаблон приводить данные к выбранному варианту.
Откуда данные берутся в шаблоне?
В любой реализации MVC-архитектуры они передаются через какой-то служебный массив или объект.
Вот там их и можно приводить к единому виду согласно собственным соглашениям.
Можно ли как-то попасть в списки тех, кого будут заранее (недели за две хотя бы) уведомлять о Tizen-мероприятиях в России?
Сегодня основой успешного бизнеса является монополия: сделай самый лучший сервис в какой-то нише, собери на своих серверах миллионы пользователей, и снимай сливки. Если же ты делаешь децентрализованный сервис, то копию твоего сервиса может поднять кто угодно, у тебя нет монополии, ты не можешь зарабатывать за счёт базы пользователей.
Все идеи того, как должны быть устроены децентрализованные социальные сети и другие сервисы, — эти идеи уже проработаны и обдуманы тысячами учёных и энтузиастов по всему миру. Но на разработку самого ПО, реализующего их, на описание протоколов и стандартов нужно много времени, а значит — денег. А денег на это никто не даст, потому что децентрализация противоречит сегодняшним моделям бизнеса. Также децентрализация является страшным сном для спецслужб и пугает государства, поэтому финансирования из бюджетов тоже ждать не приходится.
Одна из возможных моделей — краудфандинг. Но даже те, кто затеят такой проект, должны быть готовы на то, что это не станет их бизнесом и не сделает их богатыми. Максимум — даст среднюю по рынку зарплату на неопределённый период.
Высота 100–130 см.
PS: Я вообще не люблю колёсики на стульях. Устойчивость важнее ))
Хотелось бы типа такого, но с возможность подниматься на пол метра ))
А что, если стол изначально сделать только под вариант стоя, а когда хочется посидеть — садиться на высокий стул типа барного.
То есть почему стул обязательно должен быть низким?
А почему проект «не жив»? Стало неактуально?
Может, я неверно понимаю «наследование шаблонов»?
Можно конкретный пример, кусок кода?
А я попробую описать, как бы я это сделал на чистом PHP.
Но вот тут уже пошла вкусовщина, так что предлагаю на этом остановиться.
Спасибо за мнение.
Руками всё это уже реализовано до нас во фреймворках.
Ничего сложного и страшного в такой реализации нету. И в том числе можно делать это lazy-путём.
В том же «Битриксе» есть те же редактируемые области в шаблоне и шаблоны компонентов, которые вполне себе наследуются внутри сайта/шаблона сайта/шаблона компонента/директории/страницы.
Шаблон позволяет разделять подготовку и отображение данных.
Разделить данные и отображение позволяет модель MVC. Это делается на уровне архитектуры проекта. Например, файлы шаблонов лежат в отдельной директории.
А совместная работа достигается с помощью систем контроля версий. При чём тут вообще шаблонизаторы?
> Язык шаблонизатора имеет упрощенный синтаксис, поэтому ему гораздо проще научить новичка.
Простейшие конструкции и в PHP вовсе не сложны.
А новичёк потом вырастет и всё равно будет вынужден либо выучить PHP, либо уйти в своей специализации от кодинга под шаблонизатор.
Хотя изменение формата передачи данных — это следствие неудачного решения на каком-то этапе.
Да и вообще должно быть единообразие: либо массивы, либо объекты.
А перед выводом в шаблон приводить данные к выбранному варианту.
В любой реализации MVC-архитектуры они передаются через какой-то служебный массив или объект.
Вот там их и можно приводить к единому виду согласно собственным соглашениям.
UPD: Пример реализации: github.com/yiisoft/yii2/blob/master/framework/yii/base/Component.php#L28