Как стать автором
Обновить
49
0
Андрей Губский @Ernado

Software architect, Microsoft MVP

Отправить сообщение
Я как раз ходил по ссылке. Там бред полный написан.
Это такой оригинальный способ хабра-суицида?
Сначала думал прокомментировать детально каждый пункт, но потом понял что времени и текста уйдет много, а толку от этого все-равно не будет :)

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

Сам принимал участие в подобных внедрениях, поэтому говорю основываясь на реальном опыте, а не на гипотетических «конторах».

И да, есть еще Office 365.
Кстати да, очень распространенный сценарий, когда корпоративная почта переводится на локальные Exchange-сервера.
Помню еще в университете ставил .NET 2.0 (а это по сути ядро 3.5) под Windows 98
В некоторых случаях, как раз проще заплатить за готовый продукт, чем тратить время и заниматься администрированием, поддержкой и т. д.
Тем более когда продукт удовлетворяет всем основным требованиям.
Вы вернулись, ура!
Планируется ли поддержка SQL Server?
№10. Торгуйтесь с кандидатами!
Очень ИМХО, но — никогда не торгуюсь. У меня обычно есть два варианта.
Либо заказчик называет цифру которую он готов платить и я соглашаюсь, или нет.
Либо я называю свою цену — после этого заказчик говорит согласен он работать, или нет.

Если со стороны заказчика начинается торг — я обычно отказываюсь от такого проекта.

Да еще один момент. Сразу оговаривается то, что в случае дополнительных работ (например в ТЗ что-то не указали, или имели ввиду одно, а написали другое, и т.п.) они оцениваются отдельно. А в случае возникновения багов, или недоработок — исправления вносятся за мой счет.

Это еще раз повторюсь жуткое ИМХО, но как показала практика — очень способствует правильной фильтрации проектов и благополучному сотрудничеству в дальнейшем.
Сначала как раз были вариант Field1, Field2 и Title, Description но потом подумал, что так будет лаконичнее. В реальной практике же поля в БД так никогда не заываю )
Как по мне — очень спорный вариант. Для поддержаия целостности данных затрачивается много ресурсов. Однако, как мне кажется такой вариант может быть реализован в очень крупном проекте, но там это будет уже скорее шагом к масштабированию, нежели к локализации.
Тоесть, наример для портала у которого есть скажем 100 публикаций — оригиалы хранятся в БД, 20 ручных переводов хранятся в файлах, для остальных 80 в случае обращения переводы гененируются автоматически и также сохраняются в файлы?
Нет ли у вас проблем с контролем целостности данных при таком подходе?
Выборка перевода идет не по ключу, а по like текстового поля, я првильно понял?
B и С только для примера. В таблице может быть много полей требующих перевода на разные языки. Напрмиер — Title, Description, Content и так далее.
Я так понимаю в вашем случае речь идет только о переводе интерфейса? Данные не переводятся? Или просто нет необходимости одну и ту же сущность отображать на разных языках?
Поддерживаю!

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

Тким образом получается, что на таких потребителях как я кинотеатры все равно не зарабатывают, а владельцы фильмов теряют возможную прибыль
Ну набивать структуру БД тоже не обязательно — Management Studio позволяет достаточно удобно визуально проектировать структуру, которую потом при помощи того же Entity Framework можно перенести в код.
Так я же не в претензии )
Главное, что статья хорошая, а рисунок не жалко )
Увидев картинку из своего поста на минуту испытал когнитивный диссонанс, потом вчитался и понял что это другой пост))
За статью спасибо.
Дома — MacBook 13" + экран 22" + клавиатура + мышь
В офисе — HP Pavilion 15" + экран 22" + клавиатура + мышь

Стационарным компьютером пользовался лет 5 назад. После того как купил ноут, примерно через пол года отдал десктоп отцу, себе оставил только монитор и клавиатуру.

С ноутом иногда приятно выйти в сад, поработать под пение птичек :)
То есть вы считаете, что развитие Стажер -> Джуниор -> Мид -> Тимлид-Сениор -> Руководитель априори провальный?
Тогда мне придается вас разочаровать.

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

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

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Архитектор программного обеспечения
Ведущий
C#
ASP.NET
.NET
ООП
Высоконагруженные системы
Проектирование архитектуры приложений
Создание архитектуры проектов
Разработка программного обеспечения