Announcement
· Jan 13, 2023

InterSystems Developer Tools Contest

Hey Developers,

We'd like to invite you to join our next contest dedicated to creating useful tools to make your fellow developers' lives easier

🏆 InterSystems Developer Tools Contest 🏆

Submit an application that helps to develop faster, contributes more qualitative code, and helps in testing, deployment, support, or monitoring of your solution with InterSystems IRIS.

Duration: January 23 - February 12, 2023

Prize pool: $13,500

 

The topic

💡  InterSystems IRIS developer tools 💡

In this contest, we expect applications that improve developer experience with IRIS, help to develop faster, contribute more qualitative code, help to test, deploy, support, or monitor your solution with InterSystems IRIS.

General Requirements:

  1. Accepted applications: new to Open Exchange apps or existing ones, but with a significant improvement. Our team will review all applications before approving them for the contest.
  2. The application should work on InterSystems IRIS Community Edition.
  3. Types of applications that match: UI-frameworks, IDE, Database management, monitoring, deployment tools, etc.
  4. The application should be an Open Source application and published on GitHub. 
  5. The README file to the application should be in English, contain the installation steps, and contain either the video demo or/and a description of how the application works.
  6. One developer can enter the competition with a maximum of 3 applications.

Prizes

1. Experts Nomination - a specially selected jury will determine the winners:

🥇 1st place - $5,000 

🥈 2nd place - $3,000 

🥉 3rd place - $1,500

🏅 4th place - $750

🏅 5th place - $500

🌟 6-10th places - $100

2. Community winners - an application that will receive the most votes in total:

🥇 1st place - $1000 

🥈 2nd place - $750 

🥉 3rd place - $500

If several participants score the same amount of votes, they all are considered winners, and the money prize is shared among the winners.  

Important Deadlines:

🛠 Application development and registration phase:

  • January 23, 2023 (00:00 EST): Contest begins.
  • February 5, 2023 (23:59 EST): Deadline for submissions.

 Voting period:

  • February 6, 2023 (00:00 EST): Voting begins.
  • February 12, 2023 (23:59 EST): Voting ends.

Note: Developers can improve their apps throughout the entire registration and voting period.

Who can participate?

Any Developer Community member, except for InterSystems employees. Create an account!

👥 Developers can team up to create a collaborative application. Allowed from 2 to 5 developers in one team.

Do not forget to highlight your team members in the README of your application – DC user profiles.

Helpful resources

✓ Example applications:

✓ Templates we suggest to start from:

✓ For beginners with IRIS:

✓ For beginners with ObjectScript Package Manager (ZPM):

✓ How to submit your app to the contest:

Need Help?

Join the contest channel on InterSystems' Discord server or talk with us in the comment to this post. 

We can't wait to see your projects! Good luck 👍


By participating in this contest, you agree to the competition terms laid out here. Please read them carefully before proceeding. 

 
Discussion (14)10
Log in or sign up to continue

What a contest!

It'd be great if someone could implement the tool to export Interoperability components into a local folder with every changes saved in the interoperability UI?

Currently git-source-control can do the job, but it is not complete. Some Interoperability components (e.g. business rules) are not being exported. And lookup tables are exported in an not importable format.

I published and idea regarding it.

@Evgeny Shvarov as we've covered in GitHub issues, the business rule issue is a product-level issue (in the new Angular rule editor only, not the old Zen rule editor). I clarified https://github.com/intersystems/git-source-control/issues/225 re: the importable format.

The non-"wrapped" XML export format is importable by git-source-control and, I believe, IPM itself, although not by $System.OBJ.Load. It's just a matter of preference/readability. In a package manager context being loadable by $System.OBJ.Load isn't as important, and while the enclosing <Export> and <Document> tags aren't as annoying for XML files as for XML-exported classes/routines/etc., they're still annoying and distract from the true content of the document.

Hey Developers,

Watch the recording of the Kick-off Webinar on InterSystems Developers YouTube:

⏯  [Kick-off Webinar] InterSystems Developer Tools Contest

https://www.youtube.com/embed/vVozsIzS24I
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]