New post
AllAccepted answers
Sergei Shutov · Jun 28, 2018

Please find slides for my presentation here https://www.slideshare.net/secret/bnUsuAWXsZCKrp (Modern Development Environment)

Please find repository here https://github.com/logist/wduk18 - you will need to load your own IRIS container and change "FROM" statement in Dockerfile - see http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?... for instructions. You'll also need license key because REST service will not work without it.

Sergei Shutov · Apr 3, 2018

Hi Ed,

I prefer to have real-time real-world discussion near the whiteboard to leaving comments in issue tracker.

discussion about implementation strategy

You do a whiteboard discussion and write results into your Wiki/Confluence where it's easy to find it. Then you have a code review tool to make sure you implemented it correctly

references to other issues

Don't need this

cross-references to commits

Also don't need this, just write meaningful commit messages

test hints

Talk to tester

start/due dates & time spent

I usually write date the card was created in the corner to track how old it is. Then place it in the backlog based on its urgency. Don't need anything else.

milestones

You can organise your backlog into milestones.

current status

Sprint status is obvious by looking at whiteboard. For more high-level status use wiki/confluence and update it once in a while manually.

assigned person(s)

It's either written on the card or there are "person buckets" on the whiteboard. I usually don't assign issues to people until they start working on them - so if we have capacity for 20 dev days in a sprint there will be few unassigned cards on a whiteboard and people assign themselves once they pick their next card

Issues help to collect all this information and make it available later

It's a bit scary at first to just throw away all completed issues at the end of the sprint, but in reality there's nothing wrong with it. Most of this information is available via source control, and there are not many use cases where you would need to look up an old issue to have some info that's not in source control anyway.

Sergei Shutov · Apr 2, 2018

My advise to small teams that are co-located in the same office is not to use issue tracking system at all and use physical cards on whiteboard instead. In my experience using issue tracker just adds overhead without any significant benefits compared to index cards. Obviously if you have a large or distributed team you should use something, but again the simpler the better

Here is a random example from the internet (I usually use bigger cards, A6 format - quarter of a standard paper sheet):

Another example: http://theagilepirate.net/archives/1178

Sergei Shutov · Sep 25, 2017

Hi Andre Claude,

Thank you for sharing your framework, and for great presentation at Global Summit. I'm looking forward to see your detailed article in Developers Community!

We have a documentation available online, you can link directly to it: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=TUNT_ExampleTestPortal

Also, video recording of Andre's presentation and PDF of his slides are available at https://learning.intersystems.com/course/view.php?id=664

Sergei Shutov · Jul 28, 2017

Hi Sebastian,

How do you currently determine SMP URL? Usually web server configuration is external to Cache, so there are not many options except asking user to enter SMP URL manually. That's what InterSystems is doing when connecting from external tools like Studio as well. 

Any attempt to be smart about it will sooner or later cause you problems with exotic setups like load balancers, external web servers on separate machines, etc etc

 

Cheers

Sergei

Sergei Shutov · May 24, 2017

You should definitely store your storage schema in VCS. When you first compile and install your solution into an environment, it doesn't really matter -- as you said, storage will be generated automatically during compilation. However, this will cause major issues when you'll have to upgrade your environment to a newer version of your class and keep the data.

If you had a class definition in Version 1 of your system with properties Address, Zipcode your storage schema will look like

node=$LB($ClassName,Address,Zipcode)

If in version 2 you add another property, BusinessPhone, and you kept your schema, new storage definition will look like

node=$LB($ClassName,Address,Zipcode,BusinessPhone)

And all old data will still be valid, just its BusinessPhone property will be empty

However if you didn't save your schema, new storage will be alphabetically sorted as this:

node=$LB($ClassName,Address,BusinessPhone,ZipCode)

And all old data will have its ZipCode as BusinessPhone now!

I encountered this problem a couple of times, when class definition was exported before it was compiled (and storage schema was not updated), and it was not easy to fix: you need to iterate across the whole global and rewrite it, trying to guess if it's an old data or a new one.

Hope this helps

Sergei