А при чем тут Россия и ее правосудие? Это справедливо для любой страны. Только обычно в нормальных магазинах типа амазона при продаже товара сообщают все ограничения его распространение. Например, заказать на амазоне "Героев" не удалось. Также не удалось купить ни Мак ни камеру Сони. У региональных дилеров цены в полтора-два раза дороже, но на то они и дилеры - тоже кушать хотят.
С юридической точки зрения фирма "Порше Руссланд" права - она имеет эксклюзивное право на распространение товара на территории РФ. Для какой цели вы ввозите автомобиль (для себя или же хотите перепродать) - неважно. Покупая что-то с рук на E-Bay Вы рискуете напороться на неприятности с таможней, поскольку, как я понимаю, за проблемы с локальным законодательством аукцион ответственности не несет (хоть марихуану заказывайте).
Ни в этом ни в предыдущем посте про "стадо" авторы не обозначают величину компании или проекта к которому применимы данные рассуждения. Если компания небольшая, то начальник, естественно, отвечает за свои деньги и пытается минимизировать расходы при сохранении эффективности. В больших же компаниях деньги на проект поступают из общего бюджета, и здесь задача начальников - как можно больше урвать для своего проекта, ибо чем больше через него проходит финансов, тем больше оседает в карманах. Для этого необходимо как-то мотивировать затраты. Лучший способ, озвученный еще Гоголем - это "Мертвые души". То есть души-то живые, но мертвые с профессиональной точки зрения. Это - стадо, балласт.
Они большими и не должны быть - только чтобы операционку установить. Все остальное можно хранить и на обычном диске. Где-то видел ролик, где XP стартовала с подобного диска за несколько секунд.
к великому сожалению, да. организативная структура проекта напоминает пирамиду, только перевернутую. проект в шести странах латинской америки, и в каждой из которых имеется свое рудиментарное подразделение с начальником, разработчиками, группой "внедрения". при всем этом, код для всех одинаковый и делается в испании.
Извините, но это явная попытка развода холивара. Автор выражает метафору, сравнивая стопки книг, относящихся к технологиям Java и Ruby. При этом непонятна суть метафоры: то ли Руби еще недостаточно развит, то ли все то, что делает Java можно сделать на Руби, прочитав всего две книжки. Если смысл метафоры в первом случае, то автор привел очень малую часть публикаций по Java (даже меньше 10%). Если смысл дискридитировать Java, то:
1. Одна и та же информация продублирована в нескольких книгах: (Struts, J2EE - 3 штуки, JSP - две)
2. JUnit - фреймворк сомнительной практической ценности.
3. Java Foundatin Classes он же Swing: технология Rich Gui Applications, мы все еще про веб говорим?
4. Web Services и XSLT - очень узкоспециализированные.
5. XDoclet - уже давно как заменен на annotations.
6. Hibernate - наверное лучший ORM фреймворк. Аналогов нет.
7. JBoss 4.0 - руководство по серверу апликаций. JBoss даже не сертифицирован J2EE.
8. Java in nutshell - действительно хорошая книга по Java. Хотя я бы порекомендовал Thinking in Java.
Обходя стороной гуманистическую точку зрения, именно выход. Осудят на 15 лет, а через 5 выпустят досрочно за хорошее поведение. А делить бизнес уже будет не с кем.
Балласт - люди, которые не могут, не хотят и не будут работать, но получают зарплату вместе с вами.
Озвученная проблема глубоко корнями уходит в структуру нашего общества. Основная идея: немногие способны, но кушать хотят все.
Я работаю в компании, где балласт в проект набирается преднамеренно. Долго думал насчет мотивов данного набора и пришел к некоторым из них:
1. "Генерал, а где твоя армия?". Многие руководители чувствуют себя более уверенными, если под их началом стоит больше народу. Однако при этом, очень важно, чтобы в проекте был хотя бы один человек, который работает.
2. "У нас нет незаменимых!". Дабы вселить в себя и окружающих ложную уверенность в заменимости людей в проекте. Обывно к человеку, который работает подсаживают лохов, чтобы тот их стал обучать. Лохи учиться не любят, и результат будет нулевой, однако тут важен сам процесс.
3. "Ура, совпадение!". Халатность отдела кадров. Зачастую девочки из отдела кадров ни в зуб ногой как проводить собеседование. Увидев в предложении о работе и резюме кандидата совпадение (например Websphere MQ), они считают что уже нашли необходимого специалиста. Как правило, начальнику проекта некогда самому проводить собеседование.
4. "Буксир". В большой компании, где делаются и сдаются много проектов, когда один из проектов заканчивается, необходимо "пристроить" освободившуюся группу разработчиков (поскольку у большинства бессрочные контракты). Проект ужу наполовину сделан, имеет свою специфику и направленность, как вдруг тебе на шею сваливаются пара-тройка мудаков, которых ты должен обучить и найти им занятие. Один из этих мудаков, который знает, что не осилит проект, обязательно начинает пытаться руководить тобой и остальными. На посылания нахуй как правило не реагирует и продолжает как ни в чем не бывало.
P.S. я работаю в проекте из 80 человек, где двое! из них делают всю! работу. Оцените соотношение балласта.
Если это не так, работник, просто обнаружив средства слежения, вправе подать иск о нарушении тайны личной жизни. И втройне подать, если не дай бог эти сведения где-нибудь всплывут!
Это понятно. А теперь представьте, что после "ведение работы с клиентом (включая написание внятного ТЗ, переговоры, оценка работ и т.д.)" заказчик вежливо (или не очень) посылает вас. И кто он после этого?
Есть вполне определенный тип заказчика - мозгоеб, который постоянно будет что-то где-то вымораживать, выискивать, выспрашивать, изменять. С одной стороны, вы все советуете послать такого. С другой же - кто будет оплачивать потраченное на подготовку время и силы?
Это понятно, что маркетологи пытаются завлечь программистов, маня удобством и краткостью кода (программисты ленивые и много писАть не любят). C# - яркий тому пример. В отличие от аскетичной и минималистичной Java, C# постоянно модифицируется в сторону угождения программистам и превращается в помойку. И даже не маркетологи определяют дальнейшую эволюцию, а программисты, которые выросли на языках типа JS.
Основной вопрос - на кой черт? Что динамические языки предлагают такого, чего нет в структурных? Никто экономически не доказал выгодность перехода от структурных языков к динамическим. Более того, существуют четкие аргументы против этого, которые не так просто решить, как кажется. В средах J2EE тоже используется декларативность и скриптинг, но в отличие от JS и иже с ними, она базируется на XML, который строго проверяется на валидность.
С точки зрения программной имплементации эти проекты не являются сложными. Стандартный набор - фронтенд, база данных, индексатор. Вся сложность этих проектов - в обеспечении горизонтальной масштабируемости.
Сложный проект - это система резервирования авиабилетов Amadeus. Система обслуживания авиалиний. Система транзакций ServiRed (с кучей фронтендов). Софтина любого банка сложнее в сто раз любого из этих проектов. Если говорить о нагрузках, то никакая википедия не сравнится по количеству запросов с биллинговой системой мобильного оператора.
Так что! PHP - это вершина айсберга для клепания дырявых ;) страничек.
А еще есть Perl и Groovy. А Вы не задавались вопросом - нафиг столько языков для реализации одной и той же задачи? Это топтание на месте - нет никакой эволюции и радикально нового шага: ассемблер - фортран - алгол - паскаль - си - си++ - java/c# - дальше что? Скриптовое семейтво? Похоже немного на вырождение.
Тот JavaScript, который был изначально встроен в браузер Netscape не имел даже нормальной спецификации. Все последующие развитие языка было связано со стабилизацией синтаксиса при остающейся совместимости с предыдущими версиями. Если бы тот же питон был взят за основу динамических страниц, мы бы избежали сегодня большого числа проблем.
В принципе - да. Не долюбливаю я их. Область их применения сильно ограничена. Возможно для рендеринга веб страницы и sql запросов более-менее подходит, но для серьезных проектов - увы. Хотя бы для написания фреймворков и api для тех же языков.
1. Динамический (скриптовый). Эволюция структурных языков шла в направлении усиления контроля над действиями программиста, тогда как скриптовые языки исходили из соображений удобства программирования. Удобство и правильность не всегда совместимы (взгляните например спецификацию Ада). В результате статистика ошибок в динамическом языке в несколько раз больше.
2. Нестрогий контроль типов. Меньше ошибок удается отследить в момент компиляции (которой судя по всему нет). Кстати, все нововведения ES4 касаются как раз структур данных и контроля типов, но опять же, не строго.
3. Собственно runtime-контроль. Фазы компиляции и предварительной проверки, похоже, нет. Все ошибки - в момент интерпретации.
4. Сложность и избыточность (неминимальность). Отсутствие минимального "ядра" языка. Кстати, на сайте я так и не нашел строгого документа-спецификации языка. Взгляните, например, спецификацию Java.
5. Более чем сомнительное быстродействие имплементаций.
6. Несовместимость с предыдущими версиями языка.
Поддерживаю Java. Хотя ООП-подход в веб программировании практически не используется. ООП хорош для написания middleware и бизнес-логики. Из ООП фреймворков для веба можно назвать разве что Java Server Faces, и то ООП там используется в неявной форме.
Под ООП я понимаю не "язык с объектами", а метод программирования, при котором используется наследование, инкапсуляция и полиморфизм.
Не хочу сказать, что не разделяю точку зрения автора, однако ради полноты описания приведу контраргументы.
1. В некоторых случаях время на поиск/изучение/овладение оказывается больше, нежели на собственную имплементацию. Пример: Hibernate vs Сustom JDBC ORM.
2. Сторонние библиотеки также имеют ошибки. Одно дело, если мы говорим об отлаженном rt или apache, другое - если мы полагаемся на разработки Васи Пупкина. Собственные ошибки исправить намного быстрее и проще, нежели ошибки сторонних производителей. Иногда приходится прибегать к workarounds. Мой экспириенс в использовании графических библиотек к Java типа Substance, SwingX и Scenegraph - хождение по мукам: сыро и глючно. Проект оброс большим количеством подпорок (workarounds).
3. Как правило библиотеки предоставляют широкий функционал для покрытия разного рода задач. А зачастую в проекте требуется решить лишь одну задачу. Приходится интегрировать всю библиотеку. Пример: для чтения файла с веба лучше использовать обычный URLConnection, нежели вставлять Apache HttpClient.
4. Кострость библиотек. Собственный код проще "заточить" под решение определенной задачи, и сделать его эффективней. Пример: для своей клиентсерверной апликации я написал свой RMI фреймворк, который может работать в реальном времени на интернет коннекшнах через прокси, и вообще абстрагируется от транспорта. Сериализованные объекты оптимизированны и занимают несколько байт.
5. Зависимости. Многие библиотеки, типа apache, таскают с собой огромный ряд зависимостей. Усложняется интеграция. Пример: для интеграции Apache HttpClient требуется apache-commons, apache-logging, etc...
О критике JavaScript писалось очень много. Просто историчеки так сложилось, что он стал единственным языком для управления объектами в браузере. Для серверной части, где ограничения на язык не существует, выбор JS более чем неадекватен.
Блин, у всех mp3, которые я слышал, завалены басы. Никакими эквалайзерами не выправляется. Глубокие наушники немного спасают ситуацию, но не сильно. Вот старый дисковый Sony Walkman умел воспроизводить музыку. А деградация началась, как я услышал первый iPod. Эта хрень могла делать все, кроме своего основного предназначения. Хотя 90% населения звук побарабану - Диму Билана можно слушать на чем угодно.
Под словосочетанием "один-к-разным" Вы подразумеваете наследование.
Посмотрите как, например, наследование реализовано в JPA:
http://www.jpox.org/docs/1_2/jpa_orm/inheritance.html
Два основных принципа: все в одной таблице, либо отдельная таблица на класс.
С юридической точки зрения фирма "Порше Руссланд" права - она имеет эксклюзивное право на распространение товара на территории РФ. Для какой цели вы ввозите автомобиль (для себя или же хотите перепродать) - неважно. Покупая что-то с рук на E-Bay Вы рискуете напороться на неприятности с таможней, поскольку, как я понимаю, за проблемы с локальным законодательством аукцион ответственности не несет (хоть марихуану заказывайте).
1. Одна и та же информация продублирована в нескольких книгах: (Struts, J2EE - 3 штуки, JSP - две)
2. JUnit - фреймворк сомнительной практической ценности.
3. Java Foundatin Classes он же Swing: технология Rich Gui Applications, мы все еще про веб говорим?
4. Web Services и XSLT - очень узкоспециализированные.
5. XDoclet - уже давно как заменен на annotations.
6. Hibernate - наверное лучший ORM фреймворк. Аналогов нет.
7. JBoss 4.0 - руководство по серверу апликаций. JBoss даже не сертифицирован J2EE.
8. Java in nutshell - действительно хорошая книга по Java. Хотя я бы порекомендовал Thinking in Java.
Итого: 90% книг - мусор
Озвученная проблема глубоко корнями уходит в структуру нашего общества. Основная идея: немногие способны, но кушать хотят все.
Я работаю в компании, где балласт в проект набирается преднамеренно. Долго думал насчет мотивов данного набора и пришел к некоторым из них:
1. "Генерал, а где твоя армия?". Многие руководители чувствуют себя более уверенными, если под их началом стоит больше народу. Однако при этом, очень важно, чтобы в проекте был хотя бы один человек, который работает.
2. "У нас нет незаменимых!". Дабы вселить в себя и окружающих ложную уверенность в заменимости людей в проекте. Обывно к человеку, который работает подсаживают лохов, чтобы тот их стал обучать. Лохи учиться не любят, и результат будет нулевой, однако тут важен сам процесс.
3. "Ура, совпадение!". Халатность отдела кадров. Зачастую девочки из отдела кадров ни в зуб ногой как проводить собеседование. Увидев в предложении о работе и резюме кандидата совпадение (например Websphere MQ), они считают что уже нашли необходимого специалиста. Как правило, начальнику проекта некогда самому проводить собеседование.
4. "Буксир". В большой компании, где делаются и сдаются много проектов, когда один из проектов заканчивается, необходимо "пристроить" освободившуюся группу разработчиков (поскольку у большинства бессрочные контракты). Проект ужу наполовину сделан, имеет свою специфику и направленность, как вдруг тебе на шею сваливаются пара-тройка мудаков, которых ты должен обучить и найти им занятие. Один из этих мудаков, который знает, что не осилит проект, обязательно начинает пытаться руководить тобой и остальными. На посылания нахуй как правило не реагирует и продолжает как ни в чем не бывало.
P.S. я работаю в проекте из 80 человек, где двое! из них делают всю! работу. Оцените соотношение балласта.
Если это не так, работник, просто обнаружив средства слежения, вправе подать иск о нарушении тайны личной жизни. И втройне подать, если не дай бог эти сведения где-нибудь всплывут!
Есть вполне определенный тип заказчика - мозгоеб, который постоянно будет что-то где-то вымораживать, выискивать, выспрашивать, изменять. С одной стороны, вы все советуете послать такого. С другой же - кто будет оплачивать потраченное на подготовку время и силы?
Основной вопрос - на кой черт? Что динамические языки предлагают такого, чего нет в структурных? Никто экономически не доказал выгодность перехода от структурных языков к динамическим. Более того, существуют четкие аргументы против этого, которые не так просто решить, как кажется. В средах J2EE тоже используется декларативность и скриптинг, но в отличие от JS и иже с ними, она базируется на XML, который строго проверяется на валидность.
Сложный проект - это система резервирования авиабилетов Amadeus. Система обслуживания авиалиний. Система транзакций ServiRed (с кучей фронтендов). Софтина любого банка сложнее в сто раз любого из этих проектов. Если говорить о нагрузках, то никакая википедия не сравнится по количеству запросов с биллинговой системой мобильного оператора.
Так что! PHP - это вершина айсберга для клепания дырявых ;) страничек.
Тот JavaScript, который был изначально встроен в браузер Netscape не имел даже нормальной спецификации. Все последующие развитие языка было связано со стабилизацией синтаксиса при остающейся совместимости с предыдущими версиями. Если бы тот же питон был взят за основу динамических страниц, мы бы избежали сегодня большого числа проблем.
1. Динамический (скриптовый). Эволюция структурных языков шла в направлении усиления контроля над действиями программиста, тогда как скриптовые языки исходили из соображений удобства программирования. Удобство и правильность не всегда совместимы (взгляните например спецификацию Ада). В результате статистика ошибок в динамическом языке в несколько раз больше.
2. Нестрогий контроль типов. Меньше ошибок удается отследить в момент компиляции (которой судя по всему нет). Кстати, все нововведения ES4 касаются как раз структур данных и контроля типов, но опять же, не строго.
3. Собственно runtime-контроль. Фазы компиляции и предварительной проверки, похоже, нет. Все ошибки - в момент интерпретации.
4. Сложность и избыточность (неминимальность). Отсутствие минимального "ядра" языка. Кстати, на сайте я так и не нашел строгого документа-спецификации языка. Взгляните, например, спецификацию Java.
5. Более чем сомнительное быстродействие имплементаций.
6. Несовместимость с предыдущими версиями языка.
Под ООП я понимаю не "язык с объектами", а метод программирования, при котором используется наследование, инкапсуляция и полиморфизм.
1. В некоторых случаях время на поиск/изучение/овладение оказывается больше, нежели на собственную имплементацию. Пример: Hibernate vs Сustom JDBC ORM.
2. Сторонние библиотеки также имеют ошибки. Одно дело, если мы говорим об отлаженном rt или apache, другое - если мы полагаемся на разработки Васи Пупкина. Собственные ошибки исправить намного быстрее и проще, нежели ошибки сторонних производителей. Иногда приходится прибегать к workarounds. Мой экспириенс в использовании графических библиотек к Java типа Substance, SwingX и Scenegraph - хождение по мукам: сыро и глючно. Проект оброс большим количеством подпорок (workarounds).
3. Как правило библиотеки предоставляют широкий функционал для покрытия разного рода задач. А зачастую в проекте требуется решить лишь одну задачу. Приходится интегрировать всю библиотеку. Пример: для чтения файла с веба лучше использовать обычный URLConnection, нежели вставлять Apache HttpClient.
4. Кострость библиотек. Собственный код проще "заточить" под решение определенной задачи, и сделать его эффективней. Пример: для своей клиентсерверной апликации я написал свой RMI фреймворк, который может работать в реальном времени на интернет коннекшнах через прокси, и вообще абстрагируется от транспорта. Сериализованные объекты оптимизированны и занимают несколько байт.
5. Зависимости. Многие библиотеки, типа apache, таскают с собой огромный ряд зависимостей. Усложняется интеграция. Пример: для интеграции Apache HttpClient требуется apache-commons, apache-logging, etc...
Так что - выбирай, но осторожно.
Посмотрите как, например, наследование реализовано в JPA:
http://www.jpox.org/docs/1_2/jpa_orm/inheritance.html
Два основных принципа: все в одной таблице, либо отдельная таблица на класс.