Да не говори, та же проблема. При чем, абсолютно та же. Сегодня нвчальник посоветовал обновиться до Вин 8, ничего хорошего от этого не получил, только граб надо теперь восстанавливать. Что касается ГУИ, остановился на гноме 3, они его сейчас подлатали. Но проблема, как и всегда, в софте, работает через раз. Причем до обновления нормально, после фигня. И так с каждым очередным обновлением. А так, в принципе, все устраивает, кроме пары моментов:
1. Когда используешь guake, после его деактивации фокус не переходит на окно предыдущего оконного приложения
2. Меню переключения сежду окнами не очень нравится В частности объеденение, все бы хорошо, если бы похал нормально eclipse, меню консоли которого выношу на второй монитор — получается, как два отдельно запущенных окна.
3. Почтовый клиент. Thunderbird корректно не обрабатывает нотификации с календаря и не отображает изображения в письмах(дополнений на это не нашел). Evolution не умеет архивировать письма, имеет кучу не нужного функционала и при этом весь этот функционал вынесен в очень не удобный интерфейс. Про остальные майл-клиенты вообще молчу.
Что касается крупных иконок, настроек и тому подобных вещей. Да, здесь надо немного покопаться в настройках системы. В Гном 2 по началу точно такие же пляски с бубном были.
На Линуксе уже 5 лет, и каждый раз, как пытаюсь перейти на новый Виндовс, понимаю, что останусь все-таки на Линуксе.
Мне интересно другое, у нас в стране не одно законодательство с этим не согласовано. 152-ФЗ, 23 статья конституции, по-моему, говорят об обратном. Посмотрим, как скайп обновит лицензионное соглашение.
Hibernate — удобная штука, а то бы никто его не использовал. Вы можете организовать хорошую связь с бд, и вам не надо париться с вытаскиванием информации с PreparedStatement и сложными запросами SQL, вам просто достаточно грамотно связать данные и БД.
Но и в Хибернейт есть свои минусы, как и в любой другой технологии. Работу с очень большими БД лучше не осуществлять через Хибернейт(здесь стоит использовать JDBC).
Тогда, думаю, стоит исходить из каких-то определенных критериев. К примеру, величина основной задачи, то есть если большая задача требует ООП, а мелкие нет, придется использовать ООП. Или если очень много задач средней величины, а одна большая, и только она требует ООП, то применять парадигму, подходящую для задач средней величины.
Все же относительно. Никто не станет кидаться с ООП, не оценив предварительно его уместность, так же и с другими парадигмами.
Может, заказчик хочет, чтобы код был машинно-независимый, тогда даже не смотря на то, что для решения задачи лучше всего подойдет С или С++, их уже нельзя использовать. Ну и так далее.
На мой взгляд, если вы пришли в компанию по разработке приложений, то со стороны работодателя не устроить вам испытательный срок, пусть даже формально, просто глупо, либо вы — очень хороший специалист, но и это, как мне кажется, не исключет наличие испытательного срока. Если смотреть ТК, нарыть можно очень многое, но вас же интересует работа, а не то, насколько работодатель следует закону. И у вас есть огромное преимущество перед работодателем, вы всегда можете уволитьмя, если вас что-то не устраивает.
Что-то как-то все печально. Какая разница, что о вас думает работодатель? У вас всегда есть испытательный срок, чтобы изменить его мнение.
Ну, и в конце концов, если у вашего работодателя такие мысли, то зачем вам такая работа?
Про паттерны с вами не соглашусь. Если это правильно применять, то это — хорошая штука. Конечно, если городить их, где не попадя, то вреда больше, чем пользы. Да и, на самом деле, хороший программист сам применяет паттерны к приложениям, если это требуется, и зачастую не знает, что это паттерн, но знать их нужно, на всякий случай.
Но я склонен думать, что раз уж здесь речь идет об ООП, поэтому и задачи решаются соответсвующие. То есть мы не используем ООП для того, что сложить два числа. Круг задач, решаемый кадждой парадигмой, это тема отдельной статьи.
Я не могу сказать, что большой специалист. Каждому, как говорится, свое. Кому как удобно, тот так и пишет. Когда я перелез с процедурного программирования на ООП, меня многое очень порадовало. По крайней мере, не было кучи хлама в коде, потому что старался делать все по книжкам. Что касается книг по ООП, то стоит прочитать Гради Буча, «Thinking in Java» и, недавно вышедшую, «Изучаем Java» от HeadFirst, в этих книгах все очень хорошо написано, как про ООП, так и про Java. А что касается сравнения языков программирования, то, на мой взгляд, с ООП хорошо работать только на «чистом-ООП» языке(как называет это автор), потому что на остальных вы так или инче будете отходить от концепции, потому что это позволено(яркий пример — С++)
1. Когда используешь guake, после его деактивации фокус не переходит на окно предыдущего оконного приложения
2. Меню переключения сежду окнами не очень нравится В частности объеденение, все бы хорошо, если бы похал нормально eclipse, меню консоли которого выношу на второй монитор — получается, как два отдельно запущенных окна.
3. Почтовый клиент. Thunderbird корректно не обрабатывает нотификации с календаря и не отображает изображения в письмах(дополнений на это не нашел). Evolution не умеет архивировать письма, имеет кучу не нужного функционала и при этом весь этот функционал вынесен в очень не удобный интерфейс. Про остальные майл-клиенты вообще молчу.
Что касается крупных иконок, настроек и тому подобных вещей. Да, здесь надо немного покопаться в настройках системы. В Гном 2 по началу точно такие же пляски с бубном были.
На Линуксе уже 5 лет, и каждый раз, как пытаюсь перейти на новый Виндовс, понимаю, что останусь все-таки на Линуксе.
Но и в Хибернейт есть свои минусы, как и в любой другой технологии. Работу с очень большими БД лучше не осуществлять через Хибернейт(здесь стоит использовать JDBC).
Все же относительно. Никто не станет кидаться с ООП, не оценив предварительно его уместность, так же и с другими парадигмами.
Может, заказчик хочет, чтобы код был машинно-независимый, тогда даже не смотря на то, что для решения задачи лучше всего подойдет С или С++, их уже нельзя использовать. Ну и так далее.
Ну, и в конце концов, если у вашего работодателя такие мысли, то зачем вам такая работа?