посмотрел сейчас свой комментарий к яндекс-пробкам. сравнил отнешение к ай-пробкам. получаетс, что тут [в ай-пробках] реализовано то, чего мне не хаватало там (качественная карта), и не реализовано — что там было (оффлайн версия этой карты) :)
ну и да. я действительно хочу чтобы под рукой была оффлайн версия карты (более или менее приличная по детализации), а сами пробки мне и не нужны в общем-то.
а есть какой-нибудь удобный способ грузануть карту для выбранного города целиком? удобный — когда не требуется её пролистывать во всех масштабах.
было бы здорово это сделать по вай-фаю, а потом уже только подгружать по gprs дорожную обстановку.
и сколько кстати весит вся карта Питера и Лен. области?
в примере из раздела «Пофантазируем» можно ли организовать какую-то обработку исключительных ситуаций (выделил, чтобы было более заметно про что речь в потоке комментариев). например, если одна из машин недоступна — сеть отвалилась, что произойдёт? возможно ли как-то сделать так, чтобы скрипт отработал до конца не вываливаясь с ошибкой, и в каком-нибудь виде проинформировал, что, во-первых, были косяки, а во-вторых, что конкретно это были за косяки.
спасибо.
что понравилось:
1) что карты уже зашиты в программу (хоть и старые), и не надо каждый раз их качать из инета
что не понравилось:
1) первое что бросается в глаза — пиксели при большом увеличении; нигде больше в айфоне нет таких страшных пикселей :)
2) карта не понравилась. что уж там. дома мне не нужны, но ещё один уровень увеличения был бы очень кстати (к тому, что на принтскрине); не понравилось, что нельзя увеличить так же как центр и окраины. мне например не очень нужен Киев или ваша Москва, и вот за счёт их было бы круто видеть Питер получше и целиком.
приложение тем не менее оставлю в телефоне.
спасибо! :)
в больших проектах — с тем чем я сталкивался — не ограничиваются какой-то одной технологией/языком; как правило, составные части писаны на разных языках и это всех до некоторой степени устраивает.
так вот мне интересно, насколько эффективно, грубо говоря, вложение денег в реализацию какой-то части очередной системы на том или ином языке. для этого помимо технических вещей (что одно в таких-то случаях эффективнее другого по производительности, а в других — нет) нужно понимать ещё и финансовую и социальную сторону вопроса.
меня всё равно не будет на встрече, я уже написал выше. но смотреть выступления потом собираюсь. и подобные вопросы я задам докладчикам, если об этом не будет рассказано. просто эта информация может быть интересна не только мне.
как-то так.
необязательно указывать цифру или порядок, но поговорить про косвенные вещи какие-то: время на обучение языку/технологиям, стоимость используемого ПО, эффективность (или неэффективность) командной работы над этой конкретной задачей, много ли специалистов на рынке труда… ну не знаю. наверняка ещё что-то можно придумать.
thevery, мне кажется, что в ваш список 1-2-3-4-(5) в посте стоит ещё добавить пункт об экономической эффективности решения (чтобы авторы подготовились, а то прямо на месте на подобный вопрос может оказаться затруднительно дать какой-то содержательный ответ).
было бы интересно узнать про этот аспект для одной и той же задачи, решённой на разных языках.
если речь идёт о веб-тематике то можно открыть веб-лансер и на основе реальных предложений создать какую-нибудь искусственную задачу. только, на мой взгляд, нужно, чтобы этим занимались люди [но не один человек], не программирующие на чём-либо из вышеперечисенного [под веб, но знакомых с программированием]. так чтобы их выбор был основан больше на каких-то вещах не связанных с конкретными возможными языками или технологиями реализации, а, например, на практической ценности конечного решения, каких-то показателях эффективности инструмента.
лично я не готов дать какое-то предложение, потому как знаю, что часть задач, например парсинг, можно эффективно писать на перле, а часть — что-то типа «напишите хабр» — на перле писать скорее всего не стоит. ну и мне, как заинтересованному лицу, парсинг бы бы более интересен :)
интересно было бы поучаствовать. любимый язык — perl :)
правда две существенные проблемы: 25-го меня не будет в питере (может я просто выложу результат — если он будет — куда; а если кому-нибудь будет интересно, то позже уже расскажу что там как); кроме этого не смогу пообещать пока не увижу задание, что будет время на разработку (ну потому что прямо сейчас есть дополнительная работа за которую платят, и просто жалко отдать сутки-двое пописать за интерес :), и зависит всё от того, есть ли уже что-то наработанное или нет по задаче.
но сам прогноз-то у них не точный. по крайней мере это касается питера с его характерной чертой — возможностью какой-нибудь тучки вдруг набежать, как следует полить дождиком и так же внезапно исчезнуть. и ни в одном прогнозе типа этого яндексовского (и yahoo, и погода.спб.ру, и гисметео) этого получасового дождика как правило не бывает.
привык уже и давно пользуюсь этим прогнозом: www.wetterzentrale.de/topkarten/tkavnmgeur.htm?name=59&art=1
он на первый взгляд может казаться чутка непонятным, но это отходит на второй план после той точности, которой он обадает.
очень редко, когда написанное там не сбывается.
вчера установил.
он, собака, после синхронизации здорово перемешал всё в ежедневнике на айфоне :(
обнаружил это уже по пути на работу, ну и не посмотреть пока, что там в iCal.
я тоже использовал css-reset и радовался. но недавно столкнулся с тем, что встраивал java-script-календарик на некоторые страницы. из-за того, что календарик написан без css-reset (а видимо с учётом особенностей основных браузеров), вёрстка этого календарика поплыла (ну то есть она не совсем испортилась и всё видно, но вся лаконичность улетучилась).
решения, лучше чем отказаться от css-reset в проекте пока не придумал (мне правда перевёрстывать немного — два десятка страниц, наверное только). может кто-нибудь подскажет?
исправлять календарик?.. совершенно не хочется лезть в этот, кем-то написанный код представляющий из себя клубок html'я, css'а и java-script'а, чтобы попытаться распутать.
посмотрел сейчас свой комментарий к яндекс-пробкам. сравнил отнешение к ай-пробкам. получаетс, что тут [в ай-пробках] реализовано то, чего мне не хаватало там (качественная карта), и не реализовано — что там было (оффлайн версия этой карты) :)
ну и да. я действительно хочу чтобы под рукой была оффлайн версия карты (более или менее приличная по детализации), а сами пробки мне и не нужны в общем-то.
было бы здорово это сделать по вай-фаю, а потом уже только подгружать по gprs дорожную обстановку.
и сколько кстати весит вся карта Питера и Лен. области?
спасибо.
1) что карты уже зашиты в программу (хоть и старые), и не надо каждый раз их качать из инета
что не понравилось:
1) первое что бросается в глаза — пиксели при большом увеличении; нигде больше в айфоне нет таких страшных пикселей :)
2) карта не понравилась. что уж там. дома мне не нужны, но ещё один уровень увеличения был бы очень кстати (к тому, что на принтскрине); не понравилось, что нельзя увеличить так же как центр и окраины. мне например не очень нужен Киев или ваша Москва, и вот за счёт их было бы круто видеть Питер получше и целиком.
приложение тем не менее оставлю в телефоне.
спасибо! :)
так вот мне интересно, насколько эффективно, грубо говоря, вложение денег в реализацию какой-то части очередной системы на том или ином языке. для этого помимо технических вещей (что одно в таких-то случаях эффективнее другого по производительности, а в других — нет) нужно понимать ещё и финансовую и социальную сторону вопроса.
меня всё равно не будет на встрече, я уже написал выше. но смотреть выступления потом собираюсь. и подобные вопросы я задам докладчикам, если об этом не будет рассказано. просто эта информация может быть интересна не только мне.
как-то так.
но мне бы было интереснее, чтобы конкретная трактовка всё же не навязывалась.
а сравнивает и делает выводы после докладов уже каждый для себя сам на основе этих данных.
необязательно указывать цифру или порядок, но поговорить про косвенные вещи какие-то: время на обучение языку/технологиям, стоимость используемого ПО, эффективность (или неэффективность) командной работы над этой конкретной задачей, много ли специалистов на рынке труда… ну не знаю. наверняка ещё что-то можно придумать.
было бы интересно узнать про этот аспект для одной и той же задачи, решённой на разных языках.
лично я не готов дать какое-то предложение, потому как знаю, что часть задач, например парсинг, можно эффективно писать на перле, а часть — что-то типа «напишите хабр» — на перле писать скорее всего не стоит. ну и мне, как заинтересованному лицу, парсинг бы бы более интересен :)
правда две существенные проблемы: 25-го меня не будет в питере (может я просто выложу результат — если он будет — куда; а если кому-нибудь будет интересно, то позже уже расскажу что там как); кроме этого не смогу пообещать пока не увижу задание, что будет время на разработку (ну потому что прямо сейчас есть дополнительная работа за которую платят, и просто жалко отдать сутки-двое пописать за интерес :), и зависит всё от того, есть ли уже что-то наработанное или нет по задаче.
а так — идея очень нравится.
но сам прогноз-то у них не точный. по крайней мере это касается питера с его характерной чертой — возможностью какой-нибудь тучки вдруг набежать, как следует полить дождиком и так же внезапно исчезнуть. и ни в одном прогнозе типа этого яндексовского (и yahoo, и погода.спб.ру, и гисметео) этого получасового дождика как правило не бывает.
привык уже и давно пользуюсь этим прогнозом:
www.wetterzentrale.de/topkarten/tkavnmgeur.htm?name=59&art=1
он на первый взгляд может казаться чутка непонятным, но это отходит на второй план после той точности, которой он обадает.
очень редко, когда написанное там не сбывается.
он, собака, после синхронизации здорово перемешал всё в ежедневнике на айфоне :(
обнаружил это уже по пути на работу, ну и не посмотреть пока, что там в iCal.
решения, лучше чем отказаться от css-reset в проекте пока не придумал (мне правда перевёрстывать немного — два десятка страниц, наверное только). может кто-нибудь подскажет?
исправлять календарик?.. совершенно не хочется лезть в этот, кем-то написанный код представляющий из себя клубок html'я, css'а и java-script'а, чтобы попытаться распутать.
календарик: www.dynarch.com/demos/jscalendar/