angru: вся статья наглядно иллюстрирует всю боль разработки чего-то параллельного на питоне. Процессы очень тяжелы, да и требуют хорошего процессора. Потоки нужно очень и очень хорошо уметь готовить, чтобы программы были хотя бы не медленнее их последовательных аналогов. Много I/O? Лучше тогда использовать asyncio. Или более подходящий язык.
mkmister: Начинать изучать яву (с привязкой к БД или без неё) нужно всё равно одинаково. Без знания Java Core не обойтись в любом случае. Раз ты литературу нашёл, то изучай.
А про "уклон" я как раз-таки ответил: учи JDBC. Даже ссылки привёл. Это и есть самая суть.
mkmister: Вопрос подразумевает "я не умею гуглить/искать на тостере". Вопрос "С чего начать изучать яву/sql/любой другой язык или технологию" спрашивается тут каждую неделю. Может это станет неожиданностью, но ответы на такие вопросы не меняются годами. Учи гуглить, прежде чем спрашивать, иначе в обучении далеко не продвинешься.
Тёма Макеев: а в чём проблема оплатить, раз надо? люди и так предоставляют свои сервера и свои разработки бесплатно при некоторых условиях. ты же не удивляешься, что компы денег стоят в магазинах.
или можешь форкнуть cloud9 v2 и сделать так, как нужно. ну и предоставлять свой сервис всем бесплатно.
или арендуй сервак (или свой поставь с белым IP), запусти на нём бесплатную IDE, и подключайся через RDP/TeamViews/X.org
Amurchikus: Да. И если ты добавлял аннотации @Table @Column и ещё некоторые, Idea (если ты используешь её) даже может связать это с datasource и подсвечивать, есть ли такие поля в таблицах.
Но заранее хочу сказать, не стоит доверять полностью генерацию хибернейту. Например, он не знает как в постгресе правильно создавать автоинкрементальные (SERIAL PRIMARY KEY) поля (через аннотацию @GeneratedValue). Через аннотации это решается путём создания sequence (тоже через аннотации). Или можно чётко проставить диалект (вроде должно помочь и генерировать SERIAL в sql, но не факт).
Кароч, много ньюансов, некоторые постигаются после гугления... Если есть возможность генерить таблицы руками и/или с помощью нормальных инструментов миграции, то лучше использовать их. Если же таблицы часто меняются, то на первое время автогенерация прокатит.
denisramus: Когда я учился в моде был Кормен (3-е издание вышло в 2009) и немного Вирт. Кнут тоже неплох, но там больше матана. Может сейчас что-то есть более современное/практичное/лёгкое, я не знаю.
Amurchikus:
Hibernate сам сможет из сущности сгенерировать ddl для таблиц. Имена столбцов возьмёт в виде строкового представления полей у которых есть публичные геттеры/сеттеры. Название таблицы - имя класса. Внешние ключи - имя связанной сущности + _id.
Но лучше всё самому описать аннотациями. Вот список частоиспользуемых, там уж сам погугли про их значения и параметры (например, вот хороший сайт с описанием):
Станислав Макаров: Ну вот в питоне инкапсулировать что-то можно только через замыкания. Все поля объектов - публичные. Но ничего, есть договорённости об именовании. Тот, кто использует библиотеку вполне может получить "приватный" член класса. Но это как бы будут его проблемы.
>> Ну и к слову: наследование классов нарушает инкапсуляцию (для protected-полей и методов).
> м, каким образом?
Protected-поля не доступны другим классам, однако доступны классам-наследникам. От внешнего мира их прячут, потому что они инкапсулируют детали реализации публичных методов. Но в дочернем классе к ним есть доступ, т.е. сокрытие нарушается.
Но даже если все внутренние поля сделать private, инкапсуляция всё равно нарушится. Дочерний класс зависит от деталей реализации родительского. Мы можем изменить эти реализации и сломать работу дочернего класса. Т.е. реализация некоторых элементов дочернего класса не сокрыта от родительского.
В общем, наследование реализаций - плохо. Композиция - хорошо. Наследование интерфейсов - тоже хорошо. Описал иерархию интерфейсов, потом нужные из них реализовал. У каждого интерфейса может быть много реализаций, главное, чтобы класс не расширял другой класс. Тогда они будут независимы и не будут мешать друг другу. Как вариант, можно общую логику реализовывать в абстрактных классах, а в их наследниках реализовывать только абстрактные методы родителя.
Ринат Велиахмедов:
> Что за глупости.
Глупости - не знать этих вещей. На плюсах же пишешь, такие вещи нужно знать, чтобы писать нормальный код.
Есть куча источников, где это объясняется. Например, в Effective Java.
Или тут.
Или тут. Вот наглядный пример, к каким ошибкам это может привести (там ява, но на плюсах аналогично).
В GoF вроде тоже про это писали. Короче, инфы куча.
SolovyevMax: Моё мнение - первая будет актуальна ещё пару-тройку лет. В будущем мигрировать можно будет. благо там есть способы для этого.
Просто в текущем состоянии второй ангуляр мне не понравился. Имхо, пока ещё слишком сырой. Да и тайпскрипт - не самый лучший выбор.
Нет, томкат и джетти - не сервера приложений, а контейнеры сервлетов. На чистом tomcat/jetty не запустишь весь JavaEE-стек (ejb, jms, и др.). Но есть всякие штуки, типа OpenEjb, которые дружат с этими контейнерами. У томката для этих вещей есть отдельный проект tomee.
fman2: У меня была такая же фигня. Чтобы она не грелась, нужно было ставить проприетарные драйвера с сайта AMD.
У АМД GPU и CPU объединены (называется, вроде как APU). Так вот регуляция температуры процессора (и видюхи заодно) лежала на драйверах, и открытые дрова не умели нормально её разруливать.
Дмитрий Сергеевич: Вот такие сайты и бесят. Ок, стандартный скроллбар выглядит плохо и не всегда вписывается. Прикрути тогда кастомный, исчезающий. Но чтобы можно было зажать мышкой на него и крутить страницу.
Вот у меня, например, на тачпаде в ноуте перестал скролл работать. Что мне делать? Клавиатурой не хочу скроллить. Тем более, стрелки на этом сайте скролят по 5 пикселей. А PgUp/PgDown далеко от тачпада.
Ява проста как 3 копейки. Способов выстрелить себе в ногу в слаботипизированном пхп куда больше. Питон получше, но не все смогут правильно осилить динамическую типизацию.