C# / .NET WPF Developer – Completion of Migration of a Large Invoicing Program RAFSOFT.NET Sp. z o.o. is looking for a C# / .NET developer to complete the rewriting of a large, long-standing invoicing program to a new technology. The project involves the migration of an extensive desktop application for companies, used for invoicing, handling sales documents, contractors, records, and accounting-tax functions. The new version of the program is being created in C# / .NET, using DevExpress components. The project is already about 70% rewritten. We are looking for someone who can help bring it to completion, organize the missing elements, perform tests, and ensure the new version operates in accordance with the existing program. Scope of Work: completion of the migration of a large desktop application to C# / .NET, recreation of the functionality of the old program in the new version, maintaining as identical logic of operation, appearance, and handling as possible, working with DevExpress components, analyzing existing code and comparing the operation of the old and new versions of the program, fixing bugs, completing missing functions, and testing the application, collaborating on the final preparation of the program for deployment. Requirements: very good knowledge of C# and .NET, experience in creating desktop applications for Windows, knowledge of WPF or WinForms, experience with DevExpress or similar UI component libraries, ability to analyze a large existing project, accuracy and patience in reproducing existing functionality, ability to test one's own changes, very good ability to use AI tools supporting programming, code analysis, refactoring, and testing. Preferred: experience with legacy projects, knowledge of or previous work with Visual Basic 6.0, experience in migrating applications from older technologies to C# / .NET, knowledge of issues related to invoicing, accounting, JPK, or KSeF, experience working with large business applications. Who We Are Looking For: We are looking for a self-sufficient, precise, and technically experienced person who can enter an existing project, understand its logic, and consistently bring it to completion. In this project, it is very important not only to write new code but also to faithfully reproduce the operation of the old program — both in terms of functionality and appearance as well as handling. We also require proficiency in using AI tools in daily programming work. We are looking for someone who can use AI practically: for code analysis, bug finding, speeding up migration, creating tests, and organizing the project. About the Company: RAFSOFT.NET Sp. z o.o. is a Polish company creating software for entrepreneurs, accounting offices, and small and medium-sized enterprises. Our main product is the VAT Invoice program, supporting the daily handling of invoices, sales documents, contractors, records, and settlements in accordance with Polish regulations. We develop our own desktop applications and tools related to invoicing, accounting, KSeF, JPK, and automation of business processes. Our solutions are designed with stability, ease of use, and practical application in users' daily work in mind. Company website: www.rafsoft.net
Proposals are currently absent
Proposals are currently absent
-
Miroslav Stetsyuk 28 July 2020Вряд-ли кто-то сможет сделать обмен видео на игровом движке. Скорее это нужно сделать на Android Studio или что-то в этом роде.
-
Vladislav Miroshnik 29 July 2020О ужс) Надеюсь ты не юнити разработчик(Да и вообще почемут нет понимания что такое "Игровой Движок") Ничего не мешает тебе менять данный движок либо же дописывать свой функционал( сделать в unity можно все). Я даже больше скажу в asset store данный заказчик может купить ассет который имеет в себе уже весь функционал чатрулетки(Нужно просто встроить) Сразу скажу я не участвовал бы в разработке так как не интересно такое делать. Насчет ассета то пусть заходит смотрит, покупает и человек должен будет просто встроить данный ассет и накрутить свою графику и все) Это работы на 5 дней максимум с учетом разговоров)
-
Vladislav Miroshnik 29 July 2020Я зашел и такой " блин еще одна чатрулетка" одно и тоже. Но твой комментарий просто возмутил) Ты же еще и C# программист) Это как если человек мне скажет что мороженное с селедкой это вкусно( вот такое примерно было по ощущениям от комента) XD Не хотел что то плохое сказать или обидеть просто был удивлен комментарию)
-
Miroslav Stetsyuk 29 July 2020Капец ты фигню написал 😂 😅. Давай по порядку. Игровой движок - это среда для разработки игр. Соответственно делать на игровом движке обычные нативные приложение - бред (особенно чат-рулетку). Теперь давай вместе поднимемся немного вверх и перечитаем мое сообщение: "Вряд-ли кто-то сможет сделать обмен видео на игровом движке". Посмотри, пожалуйста, на ключевое слово вряд-ли. Я не исключаю тот факт, что на этом замечательном движке можно сделать почти все. Теперь давай посмотрим на твое сообщение: "Надеюсь ты не юнити разработчик". К твоему сожалению, я все-таки юнити разработчик, потому что если бы я не владел информацией про Unity, то не писал бы ничего. (Также, ты мог бы зайти на мой профиль и увидеть это, а не писать свое предположение) Мой опыт работы в этой программе - 4 года, и за это время я успел сделать как и игровые проекты, так и обычные нативные. Я с тобой полностью согласен, что на Unity возможно сделать такое приложение, но стоит ли оно того? Самая главная проблема, с которой я встречался - большой размер выходных APK и IPA файлов. Пустая сборка приложения для Android на Unity с текстом "Hello, World!" уже изначально весит ~20 мб. Насчёт ассетов из Asset Store, скорее всего заказчик не знал про это все, поэтому и не написал об этом, хотя да, в Asset Store есть все на все случаи жизни 😁. "Это работы на 5 дней максимум с учетом разговоров" - это слишком много. Настройка такого плагина займет максимум 1-2 дня. Насчёт "мороженного с селедкой" даже комментировать не буду 😂. Просто понимаешь, ребятки из Unity Technologies пока что не дали официальное разрешение, что "Да, Unity можно использовать для нативных приложений". С таким же успехом, если в данной ситуации исполнитель знает только C#, то можно реализовать это все на Microsoft Xamarin. Тот же самый результат, но проблем меньше. Не хотел что-то плохое сказать или обидеть, просто был удивлен твоему ответу.
-
Vladislav Miroshnik 29 July 2020Да приложение будет весить 20 метров с "Привет, Мир!"(в стандартной сборке юнити). И то даже тут можно сделать размер до 5 мегабайт или меньше если захотеть( но такие танцы с бубном не нужны).Размер приложения будет 40-80 в зависимости от нужных функций, а так же графики. И нужно ли говорить о размере файла когда почти у каждого кто будет пользоваться данным приложением места будет минимум 8 гигов под приложения. О каких размерах вообще речь?) И это единственный аргумент в свою защиту по сути?(Жду еще каких то аргументов без обобщений по типу " бред" и т.п ) (По пункту "стоит ли оно того") - Скорость разработки быстрее это первое(в разы быстрее), по денежным затратам меньше это второе, кроссплатформенность это третье.( единственный минус это размер по твоим словам?). Притом что разработка займет в 10 раз меньше времени? Насчет сроков( причем тут вообще настройка и сроки 2 дня), сроки я указал на весь проект и на встройку графики и то думаю я занизил все же, так как еще я уверен человек еще и серверную часть захочет реализовать возможно(и танцы будут по графике, которая должна быть привлекательной для пользователя). Я не спорю что нативное приложение будет быстрее и стабильнее так как пишется под "определенное устройство"( но причем тут вообще это?) Когда человек ясно поставил вопрос в заказе) Это раньше лет 10 назад был принцип (делаем долго, но идеально качественно и экономили на всем в плане железа). Сейчас принцип быстро и дешевле. Кто захочет ждать/платить огромные деньги за приложение которое будет на 10-15% быстрее работать и меньше нагружать смартфон(и то если программист который делает данной приложение понимает что он делает и у него есть огромный опыт в этом, вряд ли ты таких специалистов нативных приложений найдешь на этом украинском фрилансе, по этому в итоге приложение может получиться даже хуже). И самое смешное что даже если ты найдешь такого человека, то пользователь не заметит разницы на своем устройстве и не поймет сколько времени и денег ты влил в эти 10%)
-
Miroslav Stetsyuk 29 July 2020Во-первых, посмотри на статистику, перед тем как что-то писать. У многих людей (особенно у владельцев Apple техники) мало места на устройствах, и не все могут позволить иметь много таких приложений, которые после установки вырастают на 40-80 мб, а может быть и больше. Во-вторых, каждый проект уникален и соответственно будут уникальные проблемы. Насчёт этого проекта, я чувствую, что будут проблемы с передачей видео. Насчёт скорости разработки на Unity я с тобой полностью не согласен. Может попасться фрилансер, который будет дооолго делать этот проект 😉. Также, возможно, заказчик не знает всех тонкостей нашего мира, но при этом где-то, когда-то, что-то услышал про юнити, и поэтому он выбрал именно эту категорию. Если бы я был на месте заказчика, то я был бы рад, что фрилансеры направляют меня в нужное русло (например, к пайтонистам или чисто Android разработчиком). Во-третьих, почему ты решил, что разработать приложение на Python'е или на Android Studio будет намного дороже чем на Unity? Также, откуда ты взял информацию про 10-15%? Не стоит писать свои догадки, иначе это все превратиться в "базар". Также, я думаю, пользователи в состоянии заметить разницу между 10-20 мб и 80-100 мб. И вообще, откуда ты взял, что я против нативных приложений на Unity? Тут опять-же, все зависит от ситуации. Проект "Чат-рулетка" для юнити не подойдет, но, например, приложение, похожее на Google Home спокойно подойдет.
-
Vladislav Miroshnik 29 July 2020Мы сейчас из этого заказа сделаем мини спор" хабра " и нас забанят, так что надо все же заканчивать на высказанном мнение 😅 Или переходить в личку
-
Vladislav Miroshnik 29 July 2020Ну и да хотел бы еще добавить что на юнити создавалось очень много довольно крутых нативных приложений когда юнити использовали чисто как хороший граф движок. И получались просто отличные приложения. Не буду тут делится ссылками так как не хочу бана. Просто дополню свое мнение что нужно смотреть шире и не ставить себе границы( это для того и никак иначе).
-
Miroslav Stetsyuk 29 July 2020Ты сам себе противоречишь 😂 "Надо все же заканчивать на высказанном мнение", но при этом продолжаешь нашу беседу.
-
Vladislav Miroshnik 29 July 2020Дополняю свои мысли( я не писал что все я заканчиваю данный спор, а написал что надо бы закончить(нам обоим)). Ты написал " Вряд-ли кто-то сможет сделать " . Я привел аргумент что это сделать возможно и довольно быстро. Ты же начал топить аргументом что жрет много памяти( очень странный аргумент опять же дополню). Еще раз напишу( данное приложение сделать можно и делается оно довольно быстро и по стабильности будет довольно хорошее). По проблемам они могут возникнуть с любым человеком не важно какой он специализации все мы люди. Или с этим тоже поспоришь?) Просто после твоего комента заказчик закрыл данное объявление и тем самым ты его ввел в заблуждение.
-
Vladislav Miroshnik 29 July 2020Возможно он закрыл по другим причинам( но твой комментарий все же вводит в заблуждение).
-
Miroslav Stetsyuk 29 July 2020Ладно, это похоже на спор глухого и слепого. Я уважаю твое мнение. Спасибо за беседу. Тема закрыта.
P.S. Скажу по секрету, проект уже был закрыт до того, как я написал свое сообщение.
Current freelance projects in the category C#
Configuration: 1C UT 11 Address warehouse Zebra TC26 TSD Work via RDP Product scanning is performed in receiving, placement, picking documents, and other warehouse operations. Current problem: Warehouse workers operate through the Zebra TSD. When scanning, they do not always notice messages on the screen. It is necessary to implement different sound signals for different scanning results. Required functionality: Successful scanning and processing in 1C short sound signal. Barcode read by the scanner, but the product is not found in 1C another sound signal (different from successful). Error during warehouse operation incorrect cell; incorrect product; other address warehouse control errors. separate sound signal. Sounds should be played on the TSD via RDP. Preferences: use of WAV files or another reliable playback method; ability to add new types of sound messages in the future; minimal impact on the speed of TSD operation. Please specify in your response: Experience with UT 11 and address warehouses. Have you implemented similar tasks for Zebra TSD or other TSDs. Estimated cost and execution time. How the implementation of sound signals is planned.