Преподаватели — молодцы! Очень хорошая инициатива и практика. Думаю, что свободу творчества и самореализации надо внедрять во многих вузах, на многих специальностях.
По недостаткам уже сказали, я также был запутан картинками без подписей. Также моё местоположение через браузер не определилось ни на работе, ни дома, впрочем после ввода метро кинотеатры нашлись хорошо.
Простота и юзабилити — это не 3 кнопки на экране, над интерфейсом стоило бы хорошенько поработать. Даже не учитывая дизайн. Еще можно было бы в качестве дополнительного опыта постараться сделать завлекающую главную страницу, главная страница — это ваше лицо, и оно должно быть приятным.
Php код прост, но стоило бы поупражняться в более высоких материях — паттернах, сделать MVC без использования php фреймворков. Это инженерам нужно знать хотя бы для общего развития.
Это правда, нормальных datetime пикеров очень не хватает. Но это возможность для вас занять нишу :))
Кстати, обычные люди сталкиваются с проблемами при заполнении datetime пикеров, даже jQuery UI с нормальным плагином. Рекомендую кроме ручного заполнения поля заиметь еще и маску даты, чтобы она подсказывала человеку, что-то вроде: __.__.____ __:__
Но у некоторых людей даже с таким типом поля возникают проблемы :)))Поэтому можно еще в api сделать опцию, которая разделит date picker и time picker. Это, кстати, дополнительно упростит совмещение интерфейсов date и time picker'ов.
Без времени никак нельзя. Ведь если человек решит использовать ваше api, он должен будет знать, что если время понадобится, ему не придётся искать и разбирать новое api, в котором эта функциональность есть.
По-поводу громоздкости повторю предыдущих комментаторов: действительно награмождение кнопочек отпугнёт любого неайтишного пользователя (а скорее всего и айтишного тоже). Нужно либо их как-то разделить, либо придумать другое решение. Глаза разбегаются и нужно искать куда тыкнуть, чтобы получить желаемый результат.
Жаль, что даже к версиям XX браузеры не избавились от багов в таких важных и давно введённых «фичах»… ну, будем ждать версий XXX, благо, что сейчас все с этим делом ускорились:)
Согласен, но, писать о том, чем я не пользовался — не хотелось бы. Потому что по неопытности можно надавать вредных советов. Лучше уж их вообще не давать:) Удалять hadoop из статьи — не хотелось бы, потому что читателю может быть полезно узнать об этом решении и рассмотреть его экосистему поподробнее. Ссылка есть, там приведены почти все части экосистемы.
Если вы касались hbase или hive, если вам не трудно, вы могли бы описать их характерные черты в использовании, я добавлю в статью с вашим копирайтом:)
Спасибо за комментарий. К сожалению, OrientDB я не использовал, потому ничего путного не могу сказать про эту базу данных. Только потрогал немного, когда выбирал небольшое k-v решение, но выбрал в итоге leveldb.
Hadoop как платформа распределённых вычислений — ни при чём, это верно. Но в экосистеме hadoop находится и hdfs, и hbase, и hadoop mapreduce. Говоря о hadoop как о хранилище, мы имеем в виду весь спектр средств хранения данных в этой экосистеме. Да hdfs — прежде всего fs, но это распределённое хранилище петабайтов данных. Api hadoop'a позволяет работать с этой fs не как с набором файлов, а как с единицами данных. Разумеется, что вместо hdfs мы можем подставить туда другую реализацию файловой системы и hadoop будет работать с ней также, как с хранилищем.
Например: упомянутый мной MapFile — это не один файл, а два:) Но с помощью api hadoop'a мы можем работать с этими файлами как с индексом k-v. К слову, когда я «игрался» с hadoop, эта вещь искала слова за что-то около милисекунды в индексе inverted index, tf-idf, из 300 млн. слов, чем не реализация простейшего k-v хранилища на встроенном api?
К сожалению, я не могу рассказать ничего об hbase, так как его использует соседняя команда, а для «домашнего» использования у меня есть cassandra.
Добавил в заголовок hdfs. Просто hdfs — это тоже хранилище данных и оно совсем не реляционное:) А еще там есть структуры файлов, которые позволяют делать индексы на базе api hadoop, например, — MapFile. Очень простая, но быстрая штука, я вам скажу.
Это больше чем среда для распределённых вычислений. Я воспринимаю hadoop(hdfs) как хранилище для действительно больших данных.
Неужели так заметна просадка? Честно говоря не смотрел на скорость, надо будет обратить внимание… Для меня python — это прежде всего удобный и красивый язык.
Про монго не скажу, не клал в неё так много, а вот cassandra и hbase могут. Только надо их приготовить. У меня соседи как раз держат очень очень много данных в hbase, но потанцевать с бубном пришлось доолго.
Проблема в том, что решалось несколько задач, поэтому и сеты данных были разные. Их описание не получилось бы маленьким, могло бы запутать читателя лишней информацией. Хотя я согласен, что конкретики не хватает.
Вот насчёт schemaless и скорости вставки — по идее эти 2 преимущества многих nosql решений должны быть уже известны читателю из других статей про nosql. Но я могу дополнить статью, надо подумать как бы это оформить.
Хм, я надеялся ответить на этот вопрос статьёй… попробую ответить здесь и дополню статью.
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, cassandra, redis, hbase.
А вот придти к ответу на вопрос «что использовать» и в каком случае -, на мой взгляд, нужно самому. Путём тестирования и исследования решений конкретной задачи.
Sql писал не я, так что точно ответить не смогу, но помнится проблема там была в том, что на одном из этапов запроса до отсечения из базы тянулись около 1 млн записей, что и тормозило весь запрос, а контролировать это не получалось.
Задача по памяти выглядела как-то так: нужно выбрать из базы строки по ~200 правилам, при этом по каждому правилу надо было выбрать диапазон ключей этого правила с отсечением по лимиту
По недостаткам уже сказали, я также был запутан картинками без подписей. Также моё местоположение через браузер не определилось ни на работе, ни дома, впрочем после ввода метро кинотеатры нашлись хорошо.
Простота и юзабилити — это не 3 кнопки на экране, над интерфейсом стоило бы хорошенько поработать. Даже не учитывая дизайн. Еще можно было бы в качестве дополнительного опыта постараться сделать завлекающую главную страницу, главная страница — это ваше лицо, и оно должно быть приятным.
Php код прост, но стоило бы поупражняться в более высоких материях — паттернах, сделать MVC без использования php фреймворков. Это инженерам нужно знать хотя бы для общего развития.
Но в целом — молодцы.
p.s. Не получилось зарегистрироваться через facebook =(
Кстати, обычные люди сталкиваются с проблемами при заполнении datetime пикеров, даже jQuery UI с нормальным плагином. Рекомендую кроме ручного заполнения поля заиметь еще и маску даты, чтобы она подсказывала человеку, что-то вроде: __.__.____ __:__
Но у некоторых людей даже с таким типом поля возникают проблемы :)))Поэтому можно еще в api сделать опцию, которая разделит date picker и time picker. Это, кстати, дополнительно упростит совмещение интерфейсов date и time picker'ов.
По-поводу громоздкости повторю предыдущих комментаторов: действительно награмождение кнопочек отпугнёт любого неайтишного пользователя (а скорее всего и айтишного тоже). Нужно либо их как-то разделить, либо придумать другое решение. Глаза разбегаются и нужно искать куда тыкнуть, чтобы получить желаемый результат.
Чтобы не было недопониманий.
Если вы касались hbase или hive, если вам не трудно, вы могли бы описать их характерные черты в использовании, я добавлю в статью с вашим копирайтом:)
Например: упомянутый мной MapFile — это не один файл, а два:) Но с помощью api hadoop'a мы можем работать с этими файлами как с индексом k-v. К слову, когда я «игрался» с hadoop, эта вещь искала слова за что-то около милисекунды в индексе inverted index, tf-idf, из 300 млн. слов, чем не реализация простейшего k-v хранилища на встроенном api?
К сожалению, я не могу рассказать ничего об hbase, так как его использует соседняя команда, а для «домашнего» использования у меня есть cassandra.
Это больше чем среда для распределённых вычислений. Я воспринимаю hadoop(hdfs) как хранилище для действительно больших данных.
Про использование везде — осторожнее, общение с деньгами я бы пока mongo не доверил…
Вот насчёт schemaless и скорости вставки — по идее эти 2 преимущества многих nosql решений должны быть уже известны читателю из других статей про nosql. Но я могу дополнить статью, надо подумать как бы это оформить.
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, cassandra, redis, hbase.
А вот придти к ответу на вопрос «что использовать» и в каком случае -, на мой взгляд, нужно самому. Путём тестирования и исследования решений конкретной задачи.
Задача по памяти выглядела как-то так: нужно выбрать из базы строки по ~200 правилам, при этом по каждому правилу надо было выбрать диапазон ключей этого правила с отсечением по лимиту