Pull to refresh
6
0
Сергей @chernser

User

Send message
Тем немение нет ни одного программного продукта разработанного в России и признанного в мире. Даже 1С никому не нужен, хотя продукт бесспорно серьёзный.

Развитие ИТ — это когда специалисты страны представляют значительную долю в мировом сообществе, ИМХО.

У нас и экономистов завались — только вот экономика не очень чего то. Нужно брать не количеством.
Зря =) как практика показала болванка быстрей теряется или царапается, чем приходит время её повторного использования для установки.

Для операционки, ИМХО, уже можно LiveUSB использовать: и универсально, и быстро, и не надо озадачиваться поиском чистой болванки под новую версию системы
Еще можно по IP TV заказать
Они просто украдут идеи у остальных, и те станут похожи на Microsoft.
Для такой фигни как в примере фреймвёрк займёт больше времени.
когда вам нужна кофемолка — вы же не покупаете кухонный камбаин? Хотя он тоже умеет молоть кофе.

Так и тут — зачем мне тянуть фреймвёрк, настраивать его, отключать ненужный функционал, что бы потом может быть когда нибудь его включить?

Зачем цветочной лавке гибкость? Она предполагает торговать вооружением разных типов и разных сборок?

В ТЗ есть «написать простой магазин», так зачем писать его расширяемым? Нужно решать конкретную задачу.

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

Из задачи видно, что кучи полей не предполагается.

Но подходы безусловно разные могут быть, даже и в простецких задачах. Но всё же советую вдумываться в поставленную задачу и её перспективы =)

Как раз переферийный код в небольших проектах сводится лишь к DAO/ORM. Остальной код затачивается под конкретную задачу, ибо универсальность не нужна.

Например нужно написать магазин для цветочной лавки. Нужно:
1. Список букетов (изображение, цена, кнопка купить)
2. Форма отправить заказ (простая мейл форма со списком покупок)
3. Форма отслеживания заказа
4. Форма редактирования списка

Список товара делается одним SQL запросом и for(), который формирует страницу
Текущий список заказа хранится в сессии
Адресс, телефон, имя передаются через форму и сохраняются одним SQL запросом.
В три строчки отправляется письмо.
Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.

Зачем тут фреймвёрк? Что бы «шкурки» менять для разных магазинов? Проще сделать пару функций с общей структурой и параметром "$cssClasses", и потом просто добавить в новый дизайн.
ORM тут вообще не нужен. Максимум DAO, что бы перекрутить на другу бд. Капча, отправка письма — используем пару библиотек. Редактор списка тоже форма с двумя запросами (удалить, сохранить).
Проверку логина, пароля можно вообще средствами httpd сделать, но и свой написать не сложно (я про логин в «админку»)

Захотели добавить поле описание к товару: поправили запорос, поправили функцию отображения.

Используя фреймвёрк мы получим лишний «жир» в виде ненужного функционала + баги в нём.

Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.

В большенстве случаев приходится подстраиваться под этот «интсрумент».
Например, нет смысла писать свой DAO, когда уже есть слой доступа к БД во фреймвёрке, но иногда этот слой не соответствует извращенным требованиям проекта и пишется свой костыль, всё равно.

Не использую фреймверки.
Для небольший сайтов с парой, тройкой функций не вижу смысла тянуть целый фреймвёрк.
Для игрового проекта также решил не использовать фреймвёрк. Я сделал свою простую архитектуру, без излишеств.

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

ИМХО, чем больше проект завязан на структуру стороннего разработчика, тем сложнее делать в нём изменения. Для многих вещей приходится писать свои адаптеры и прокси. Что касается библиотек — их нужно использовать по мере возможности, так как они не задают общей структуры и их легко заменить.
Может. Но это займёт время. Человек в это время может взять такси и уехать, скажем, топиться.
Да, его околелый труп быстро найдут вниз по течению, но человека это уже не спасёт.

ИМХО, надо прививать ответственность пользователям. Только близкие друзья могут реально чем то помочь. А тут получается, что пользователь перекладывает ответственность на какую то мифическую службу, или просто отдаёт судьбу человека в руки скрипта в три строки. Сам же остаётся уверен в том, что так и надо. На мой взгляд, это приведёт к еще большему равнодушию людей.

Те кто хочет совершить самоубийство — берут и совершают, оставляя предсмертную записку.
А если человек постоянно говорит о самоубийстве — скорей всего, ему не хватает внимания, и убьётся он скорей по неосторожности, а не по собственному желанию. Последних и надо спасать.
Все хорошо, кроме того момента, как связаться с наглотавшимся таблеток человеком? Хорошо, если известен его номер телефона. Но даже при известном адресе, человек может сводить счеты с жизнью где нибудь на станции метро или лежать на рельсах n'го километра черти какой дороги.

Я говорю про востановление. Когда вы работаете на самосвале, при его поломне, не садитесь же на легковушку. Я имею ввиду, что если винда для работа/игр, всё равно её переставлять надо.

с утановленными Ubuntu + W7? =)
Ну загнётся — всё равно, как понимаю основная работа в семёрке, потому навряд ли линукс на втором винте поможет.

Тут скорей загрузочная флешка поможет, чем линукс.

А почему не используете для такого случая virtual box (или другую VM)? Интересно просто.
Думаю процентов 40%, но из них процентов 20% выберут другое, потому что дома как правило несколько ОС используют по разным причинам.

Другое интересно — степень использования.

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Date of birth
Registered
Activity