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

Потому что правовая подготовка, даже базовая, как правило у обозначенных опытных товарищей так же отсутствует. Более того нередки случаи, когда и у руководства в том числе юридического, не в всё с этим в порядке. Укоренившаяся стандартная мантра из уст таких деятелей звучит примерно следующим образом: “Ты работаешь по трудовому договору, в котором прописаны твои должностные инструкции, по которым ты в рабочее время на рабочем месте разрабатываешь ПО. Которое потом таким образом автоматически становится собственностью работодателя”. Некоторые, чуть более прошаренные, при этом ссылаются на технические задания и некие исключительные права, которыми, опять же, якобы автоматически обладает работодатель.

И это выглядит на первый взгляд настолько убедительно, что у нового наемного работника даже не возникает нотки подозрения, что здесь что-то не так. И почему на западе так носятся со всякими патентами, судами, авторскими отчислениями и прочим юридическим балластом. Часто приходится слышать и аргумент в пользу того, что наше законодательство дескать отличается от, скажем, американского, и по этому это их американские заморочки. Да и вообще кто ты такой, что бы ставить под сомнение профессиональную пригодность целого юридического отдела?

Привет, Хабр!

Меня зовут Дарморезов Вадим, я Data Scientist и участник профессионального сообщества NTA. Актуальность работы с большими объемами текстовой информации ещё долгое время (а может быть и всегда) будет неоспорима. При этом спектр задач весьма вариативен – от задач по поиску именованных сущностей, до классификации и кластеризации текстов обрабатываемых документов.

Представим ситуацию. Перед вами важная задача – классифицировать огромный поток входящих обращений сотрудников/клиентов для дальнейшего анализа профильными сотрудниками на предмет отклонений и для построения интересующих статистик. Первое решение, приходящее в голову – в ручном режиме просматривать обращения и проводить их классификацию. Спустя пару часов, приходит осознание того, что решение было не самым правильным и так задачу не выполнить в срок. Как же тогда поступить? Именно об этом будет следующий пост.

Привет, Хабр!

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

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

Примеры кода написаны на C++, исходники всей библиотеки лежат здесь. Также написана копия библиотеки на Java, исходники лежат здесь.

О Rust я слышал ещё несколько лет назад и все его либо хвалили, либо порицали, по различным причинам, но сам как-то не брался за него - мне, неподготовленному к подобному синтаксису и не знакомому с подобными языками хотя бы на базовом уровне, в то время он казался совершенно непонятным.

Не так давно решил написать для себя небольшое приложение-бенчмарк для теста HTTP API серверов и написал его на Go. Но размер в 5 с лишним Мбайт, несоблюдение целевого RPS и некоторые другие проблемы заставили посмотреть в сторону более производительного Rust + Tokio + Hyper.

Эта статья о коде Rust-приложения, переходе с Go на Rust, преимуществах и недостатках обоих языков и сравнении двух сферических коней в вакууме.

Продолжаем серию заметок для занятий математического кружка. Героем нашего сегодняшнего рассказа будет листок в клеточку. Этот образ стал своеобразным символом школьной математики. На одних из нас он навевает депрессивную тоску, а на иных, действует, как возбудитель, взывая маниакальное желание что-нибудь формулировать, строить, решать и доказывать. Равнодушных "к тетрадке в клеточку", я приглашаю просто порисовать что-нибудь: косичку или лабиринт, или, на худой конец, енота. А мы пока обсудим вот какие клеточные вопросы:

Как в тетрадке в клеточку нарисовать квадрат площадью 13 клеток так, чтобы все его вершины лежали на пересечениях сетки? Какие, вообще, квадраты можно вписать в квадратную решётку? А сколько существует способов нарисовать таким образом прямоугольник с заданной площадью? Портреты каких правильных многоугольников можно изобразить в тетрадке? Какие существуют окружности, проходящие через пересечения сетки?

Как известно, большинство UPS подключаются между розеткой 220В и NAS. При этом ничто не мешает разместить UPS внутри корпуса NAS или хотя бы позаботиться об этом заранее.

Рассмотрим вариант дизайна такого UPS, который можно разместить внутри корпуса для тех NAS, которые для работы требуют только одного напряжения питания 12В.

Задумывались ли вы, во сколько вашему бизнесу обходятся ошибки в справочниках компании? По данным Gartner — ведущей мировой исследовательской компании, неверные данные о клиентах могут стоить компании 30% ее годового дохода. С точки зрения информационных технологий, данные о клиентах относятся к мастер‑данным или, как они еще называются, — основным данным.

Поделюсь тем, что такое мастер‑данные, почему ими важно управлять и как с помощью внедрения стратегии управления мастер‑данными (master data management — MDM) сократить потери бизнеса.

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

В таких обстоятельствах использование данных становится все более трудным, если не сказать — невозможным. Причем это касается не только сложных проектов! Даже выявление наиболее прибыльных клиентов или высокомаржинальных продуктов является невыполнимой задачей, если не научиться управлять мастер‑данными.

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

В этой статье я хочу поделиться своим опытом того, как я учился вести проекты, то есть контролировать риски, планировать ресурсы и все такое.

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

А хотелось научиться, чтобы быть на уровне хорошо :) Тем более, что в последнее время больше занимаюсь ведением проектов и развитием продукта.

И так задача - научиться вести проекты.

Как реально этому научиться, какие варианты есть?

Вариант 1. Можно читать книжки, статьи на эту тему. Кому-то это поможет, но имхо это один из тех навыков, которые приобретаются не за счет изучения теории, а целиком из практики. Невозможно научиться кататься на велосипеде по книжке, сразу сев и поехав

Вариант 2. Пробовать, пробовать, набить шишки, и через N проектов вы станете хорошим продукт-менеджером, если вас не уволят или по пути вы не впадете в глубокое уныние ). Опять же так себе вариант - во-первых пока научитесь, угробите кучу проектов в ущерб своей карьере. А во-вторых это все равно что учиться водить машину с нуля без автошколы, 30 раз врезаясь в препятствие, пока поймете, что делает педаль тормоза, а что педаль газа.

Могу это подтвердить еще своим опытом создания нескольких стартапов.

К фразе "стартап не удался, но приобрели бесценный опыт" - отношусь скептически. Хороший опыт приобретается, когда видишь положительный эффект от своих усилий.

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

Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.

Привет, Хабр!

Продолжу рассказывать о впечатлениях обычного пользователя о российских ОС семейства Linux.

Кто пропустил, в первой части был Simply Linux, во второй части — Astra Linux CE Orel.
Далее...

Продолжим знакомиться с вариациями клеточных автоматов. Ранее мы рассмотрели базовую «life-like» конфигурацию и добавили к ней поколения.

Сегодня сделаем ещё один шаг – расширим правила учёта соседей так, что влиять на рождение и выживание клеток будет не только количество живых соседей, но и их расположение.

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