BR Forum

Hello everybody,

Planning for the May Business Rules Group conference is in full swing. This is YOUR conference. What do you want out of it? Time is of the essence so we can recruit presenters to give you what you want to see.

Some points to get you thinking...
What topics do you want covered?
What version of BR are you using now? What version do you WANT to use?
What language features would you like to use if you could just figure out how to use them?
What do you want to accomplish in your software that you aren't even sure HAS a solution in BR? (I bet there is one...)
Are you interested in some further clarification of a topic that was presented in the past, but it went over your head at that point because you weren't quite ready to hear it? (been there, done that...every conference)
Are you interested in moving to BR 4.3, but you don't know how to get started or are hitting some snags in doing so? (I'm in that category as we speak, so I'm sure you'll hear more from me about that as I wade through it.)

But you're not limited to BR 4.3. What general programming challenges are you facing that the group might be able to help with?
What general business-related challenges do you have that we might be able to talk about? Data security? Version control for your code? Backup solutions? Programming Editors? Finding and hiring temporary programmers to help with some of your work load? Setting up networks? Others?
Are there ways in which you'd like your programs to be more current? To have more features that "other" software out there has? Like what?
Are you looking for ways to speed up programming and be more efficient?
Do you want some one-on-one help? If so, with kind of issues? I bet I can find somebody who knows about those things and will be willing to help you.

These are just some ideas to get the conversation started and the wheels turning. They are not necessarily on the schedule for the conference, but could be if you want them to be.

This is the time to speak up. (in the next week hopefully) You can post replies here. OR if you're shy (or new to BR), and you don't want to post publicly, feel free to PM me or email me off list. Ideally, I'd love to hear something from EVERYONE.

I need your input. Please

-- Susan

What about concept ideas that we may not be using that will make our lives easier, like:
*Enumerations (http://en.wikipedia.org/wiki/Enumeration)
*Agile Software Development (http://en.wikipedia.org/wiki/Agile_software_development) or SCRUM (http://en.wikipedia.org/wiki/Scrum_%28development%29)

Or make our users lives easier like:
*Object-oriented user interface (http://en.wikipedia.org/wiki/Object-ori ... _interface)

Just a couple random ideas.

-John

Hi John,

Of those concepts you mentioned, I'm only familiar with OOUI.

I think that ScreenIO is probably the closest thing we have to working with objects in the BR world, without using a different programming language altogether, since BR by nature, is not object oriented.

I read through the wikipedia references you mentioned, and although much (most) of it is over my head at this point, I'm still curious as to how these other topics might be useful to BR programmers, specifically. What could we pull out of these topics that would improve our code or make us more productive? (I think you mentioned enumeration once before, now that I think of it.) Can you boil it down to a soundbite description for us?

-- Susan

Well - OOUI - is just the part that the users see... so we don't need a real object oriented language to design our programs to work in an object oriented way. Really simply it means instead of going from screen to screen to screen, you start off with the end in sight and then adjust it... So say you want to make a report for school. the non-ooui way might be to ask the report title, then ask for the first paragraph, then the second, etc. In the OOUI woruld you would start with a blank document and then the user would choose to add a title to that, then add a paragraph or two. One central place with options to pull in rather than a step by step to the end.

Enumberations are simple. say you have an array like Mat Color$
and Color$(1)=blue and Color$(2)=yellow, after you add 30 or 40 colors forget what color$(1) was so you make enums like:
color_blue=1 : color_yellow=2
so then you can refer to them as color$(color_yellow) and later when you edit your code you can easily see what color it is. There are several advantages to using enums. The most obvious of which is the ease of reading and remembering which is which.
Even Charlie uses enums on some leverl. Charlie taught me to always use variables for file handles. Those are simple enums and they make my life much easier. Mostly for reading and refactoring reasons.

agile and scrum terms are a higher level than programmer. they're systems administrator terms. they're more about how to manage your programmers efficiently to hit the goals and get the programs/results you need while maintaining an atmosphere that lets them innovate.

whew,
john

Thanks John. Those are good soundbite descriptions, which were exactly what I was looking for. I didn't really know what enumeration was until I started using FileIO. That's how FileIO works and you're right...it's definitely the way to go.

-- Susan