Програміст C# / .NET WPF – завершення міграції великої програми для виставлення рахунків RAFSOFT.NET Sp. z o.o. шукає програміста C# / .NET для завершення переписування великої, багаторічної програми для виставлення рахунків на нову технологію. Проект стосується міграції розширеної десктопної програми для компаній, що використовується для виставлення рахунків, обробки документів продажу, контрагентів, обліку та функцій бухгалтерсько-податкових. Нова версія програми створюється мовою C# / .NET, з використанням компонентів DevExpress. Проект вже переписаний приблизно на 70%. Шукаємо людину, яка допоможе довести його до кінця, упорядкувати відсутні елементи, виконати тести та подбати про відповідність роботи нової версії з попередньою програмою. Обсяг робіт: завершення міграції великої десктопної програми на C# / .NET, відтворення функціональності старої програми в новій версії, збереження максимально ідентичної логіки роботи, вигляду та способу обслуговування, робота з компонентами DevExpress, аналіз існуючого коду та порівняння роботи старої та нової версії програми, виправлення помилок, доповнення відсутніх функцій та тестування програми, співпраця при фінальному підготовці програми до впровадження. Вимоги: дуже добре знання C# та .NET, досвід у створенні десктопних програм для Windows, знання WPF або WinForms, досвід з DevExpress або подібними бібліотеками компонентів UI, уміння аналізувати великий, існуючий проект, точність і терпіння при відтворенні існуючої функціональності, уміння тестувати власні зміни, дуже хороша здатність користуватися інструментами AI, що підтримують програмування, аналіз коду, рефакторинг та тестування. Бажано: досвід з проектами типу legacy, знання або попередня робота з Visual Basic 6.0, досвід при міграції програм зі старих технологій на C# / .NET, знання питань, пов'язаних з виставленням рахунків, бухгалтерією, JPK або KSeF, досвід у роботі з великими бізнес-програмами. Кого шукаємо: Шукаємо самостійну, точну та технічно досвідчену людину, яка вміє увійти в існуючий проект, зрозуміти його логіку та послідовно довести його до кінця. У цьому проекті дуже важливо не лише писати новий код, але й вірно відтворити роботу старої програми — як з точки зору функцій, так і вигляду та способу обслуговування. Вимагаємо також вмілого користування інструментами AI у повсякденній програмістській роботі. Нам важлива людина, яка вміє використовувати AI практично: для аналізу коду, пошуку помилок, прискорення міграції, створення тестів та упорядкування проекту. Про компанію: RAFSOFT.NET Sp. z o.o. — це польська компанія, що створює програмне забезпечення для підприємців, бухгалтерських офісів та малих і середніх компаній. Нашим основним продуктом є програма Фактура ПДВ, що підтримує щоденне обслуговування рахунків, документів продажу, контрагентів, обліку та розрахунків відповідно до польських норм. Розвиваємо власні десктопні програми та інструменти, пов'язані з виставленням рахунків, бухгалтерією, KSeF, JPK та автоматизацією бізнес-процесів. Наші рішення проектуються з урахуванням стабільності, простоти обслуговування та практичного застосування в повсякденній роботі користувачів. Сайт компанії: www.rafsoft.net
Ставки поки відсутні
Ставки поки відсутні
-
Мирослав Стецюк 28 липня 2020Вряд-ли кто-то сможет сделать обмен видео на игровом движке. Скорее это нужно сделать на Android Studio или что-то в этом роде.
-
Владислав Мирошник 29 липня 2020О ужс) Надеюсь ты не юнити разработчик(Да и вообще почемут нет понимания что такое "Игровой Движок") Ничего не мешает тебе менять данный движок либо же дописывать свой функционал( сделать в unity можно все). Я даже больше скажу в asset store данный заказчик может купить ассет который имеет в себе уже весь функционал чатрулетки(Нужно просто встроить) Сразу скажу я не участвовал бы в разработке так как не интересно такое делать. Насчет ассета то пусть заходит смотрит, покупает и человек должен будет просто встроить данный ассет и накрутить свою графику и все) Это работы на 5 дней максимум с учетом разговоров)
-
Владислав Мирошник 29 липня 2020Я зашел и такой " блин еще одна чатрулетка" одно и тоже. Но твой комментарий просто возмутил) Ты же еще и C# программист) Это как если человек мне скажет что мороженное с селедкой это вкусно( вот такое примерно было по ощущениям от комента) XD Не хотел что то плохое сказать или обидеть просто был удивлен комментарию)
-
Мирослав Стецюк 29 липня 2020Капец ты фигню написал 😂 😅. Давай по порядку. Игровой движок - это среда для разработки игр. Соответственно делать на игровом движке обычные нативные приложение - бред (особенно чат-рулетку). Теперь давай вместе поднимемся немного вверх и перечитаем мое сообщение: "Вряд-ли кто-то сможет сделать обмен видео на игровом движке". Посмотри, пожалуйста, на ключевое слово вряд-ли. Я не исключаю тот факт, что на этом замечательном движке можно сделать почти все. Теперь давай посмотрим на твое сообщение: "Надеюсь ты не юнити разработчик". К твоему сожалению, я все-таки юнити разработчик, потому что если бы я не владел информацией про Unity, то не писал бы ничего. (Также, ты мог бы зайти на мой профиль и увидеть это, а не писать свое предположение) Мой опыт работы в этой программе - 4 года, и за это время я успел сделать как и игровые проекты, так и обычные нативные. Я с тобой полностью согласен, что на Unity возможно сделать такое приложение, но стоит ли оно того? Самая главная проблема, с которой я встречался - большой размер выходных APK и IPA файлов. Пустая сборка приложения для Android на Unity с текстом "Hello, World!" уже изначально весит ~20 мб. Насчёт ассетов из Asset Store, скорее всего заказчик не знал про это все, поэтому и не написал об этом, хотя да, в Asset Store есть все на все случаи жизни 😁. "Это работы на 5 дней максимум с учетом разговоров" - это слишком много. Настройка такого плагина займет максимум 1-2 дня. Насчёт "мороженного с селедкой" даже комментировать не буду 😂. Просто понимаешь, ребятки из Unity Technologies пока что не дали официальное разрешение, что "Да, Unity можно использовать для нативных приложений". С таким же успехом, если в данной ситуации исполнитель знает только C#, то можно реализовать это все на Microsoft Xamarin. Тот же самый результат, но проблем меньше. Не хотел что-то плохое сказать или обидеть, просто был удивлен твоему ответу.
-
Владислав Мирошник 29 липня 2020Да приложение будет весить 20 метров с "Привет, Мир!"(в стандартной сборке юнити). И то даже тут можно сделать размер до 5 мегабайт или меньше если захотеть( но такие танцы с бубном не нужны).Размер приложения будет 40-80 в зависимости от нужных функций, а так же графики. И нужно ли говорить о размере файла когда почти у каждого кто будет пользоваться данным приложением места будет минимум 8 гигов под приложения. О каких размерах вообще речь?) И это единственный аргумент в свою защиту по сути?(Жду еще каких то аргументов без обобщений по типу " бред" и т.п ) (По пункту "стоит ли оно того") - Скорость разработки быстрее это первое(в разы быстрее), по денежным затратам меньше это второе, кроссплатформенность это третье.( единственный минус это размер по твоим словам?). Притом что разработка займет в 10 раз меньше времени? Насчет сроков( причем тут вообще настройка и сроки 2 дня), сроки я указал на весь проект и на встройку графики и то думаю я занизил все же, так как еще я уверен человек еще и серверную часть захочет реализовать возможно(и танцы будут по графике, которая должна быть привлекательной для пользователя). Я не спорю что нативное приложение будет быстрее и стабильнее так как пишется под "определенное устройство"( но причем тут вообще это?) Когда человек ясно поставил вопрос в заказе) Это раньше лет 10 назад был принцип (делаем долго, но идеально качественно и экономили на всем в плане железа). Сейчас принцип быстро и дешевле. Кто захочет ждать/платить огромные деньги за приложение которое будет на 10-15% быстрее работать и меньше нагружать смартфон(и то если программист который делает данной приложение понимает что он делает и у него есть огромный опыт в этом, вряд ли ты таких специалистов нативных приложений найдешь на этом украинском фрилансе, по этому в итоге приложение может получиться даже хуже). И самое смешное что даже если ты найдешь такого человека, то пользователь не заметит разницы на своем устройстве и не поймет сколько времени и денег ты влил в эти 10%)
-
Мирослав Стецюк 29 липня 2020Во-первых, посмотри на статистику, перед тем как что-то писать. У многих людей (особенно у владельцев Apple техники) мало места на устройствах, и не все могут позволить иметь много таких приложений, которые после установки вырастают на 40-80 мб, а может быть и больше. Во-вторых, каждый проект уникален и соответственно будут уникальные проблемы. Насчёт этого проекта, я чувствую, что будут проблемы с передачей видео. Насчёт скорости разработки на Unity я с тобой полностью не согласен. Может попасться фрилансер, который будет дооолго делать этот проект 😉. Также, возможно, заказчик не знает всех тонкостей нашего мира, но при этом где-то, когда-то, что-то услышал про юнити, и поэтому он выбрал именно эту категорию. Если бы я был на месте заказчика, то я был бы рад, что фрилансеры направляют меня в нужное русло (например, к пайтонистам или чисто Android разработчиком). Во-третьих, почему ты решил, что разработать приложение на Python'е или на Android Studio будет намного дороже чем на Unity? Также, откуда ты взял информацию про 10-15%? Не стоит писать свои догадки, иначе это все превратиться в "базар". Также, я думаю, пользователи в состоянии заметить разницу между 10-20 мб и 80-100 мб. И вообще, откуда ты взял, что я против нативных приложений на Unity? Тут опять-же, все зависит от ситуации. Проект "Чат-рулетка" для юнити не подойдет, но, например, приложение, похожее на Google Home спокойно подойдет.
-
Владислав Мирошник 29 липня 2020Мы сейчас из этого заказа сделаем мини спор" хабра " и нас забанят, так что надо все же заканчивать на высказанном мнение 😅 Или переходить в личку
-
Владислав Мирошник 29 липня 2020Ну и да хотел бы еще добавить что на юнити создавалось очень много довольно крутых нативных приложений когда юнити использовали чисто как хороший граф движок. И получались просто отличные приложения. Не буду тут делится ссылками так как не хочу бана. Просто дополню свое мнение что нужно смотреть шире и не ставить себе границы( это для того и никак иначе).
-
Мирослав Стецюк 29 липня 2020Ты сам себе противоречишь 😂 "Надо все же заканчивать на высказанном мнение", но при этом продолжаешь нашу беседу.
-
Владислав Мирошник 29 липня 2020Дополняю свои мысли( я не писал что все я заканчиваю данный спор, а написал что надо бы закончить(нам обоим)). Ты написал " Вряд-ли кто-то сможет сделать " . Я привел аргумент что это сделать возможно и довольно быстро. Ты же начал топить аргументом что жрет много памяти( очень странный аргумент опять же дополню). Еще раз напишу( данное приложение сделать можно и делается оно довольно быстро и по стабильности будет довольно хорошее). По проблемам они могут возникнуть с любым человеком не важно какой он специализации все мы люди. Или с этим тоже поспоришь?) Просто после твоего комента заказчик закрыл данное объявление и тем самым ты его ввел в заблуждение.
-
Владислав Мирошник 29 липня 2020Возможно он закрыл по другим причинам( но твой комментарий все же вводит в заблуждение).
-
Мирослав Стецюк 29 липня 2020Ладно, это похоже на спор глухого и слепого. Я уважаю твое мнение. Спасибо за беседу. Тема закрыта.
P.S. Скажу по секрету, проект уже был закрыт до того, как я написал свое сообщение.
Актуальні фриланс-проєкти в категорії C#
Конфігурація: 1С УТ 11 Адресний склад ТСД Zebra TC26 Робота через RDP Сканування товарів виконується в документах приймання, розміщення, відбору та інших складських операціях. Поточна проблема: Комірники працюють через ТСД Zebra. При скануванні не завжди помічають повідомлення на екрані. Потрібно реалізувати різні звукові сигнали для різних результатів сканування. Необхідний функціонал: Успішне сканування та обробка в 1С короткий звуковий сигнал. Штрихкод зчитано сканером, але товар не знайдено в 1С інший звуковий сигнал (відмінний від успішного). Помилка при виконанні складської операції неправильна комірка; неправильний товар; інші помилки контролю адресного складу. окремий звуковий сигнал. Звуки повинні відтворюватися на ТСД через RDP. Побажання: використання WAV-файлів або іншого надійного способу відтворення; можливість у майбутньому додати нові типи звукових повідомлень; мінімальний вплив на швидкість роботи ТСД. Прошу вказати у відповіді: Досвід роботи з УТ 11 та адресними складами. Чи реалізовували подібні задачі для ТСД Zebra або інших ТСД. Орієнтовну вартість та строки виконання. Яким способом планується реалізація звукових сигналів.