New post
AllAccepted answers
Sergei Shutov · Aug 7, 2019

Just as a side comment, this has actually nothing to do with cookies. Cookies don't protect against CSRF. This is a custom HTTP header with a word "Cookie" in its name. So while it's correct it's a bit confusing.

I was not sure if checking for just presence of the header and not an actual value is enough (we assign a random value at logon time and store it in session), but apparently all browsers prevent cross-site AJAX requests so 3rd party site can't send custom header.

Sergei Shutov · Feb 17, 2019

In that case I think it would be nice to have several ways to distribute a project:

  • "compiled" / "binary" version in form of IRIS.DAT which can be added to IRIS instance as a database and then either used in separate namespace or mapped into an existing one or %All, with clear instructions on naming conventions and how to use
  • "source" which can be imported into new or existing namespace and then changed (gitHub profile is enough for this type of distribution)
  • for a standalone type of tool, a Docker image which can be easily run or used as a sample/demo
Sergei Shutov · Aug 16, 2018

You can use $zu function directly with third parameter

$ZU(171,1) returns CPU time (in milliseconds) on any OS, as a string in format SYS_time,USER_time
$ZU(171,1,pid) returns total CPU time (system + user) for process pid.

However this will return CPU time -- the time CPU was actually serving the process, not the time since process was started (when process is idle, this counter does not increase). Eduard's solution would be better if you need the total time.

Sergei Shutov · Aug 13, 2018

I believe it's enough to have [Final] keyword set in deployed mode to give a developer a hint that this class should not be extended.

If you want to enforce this behaviour, I would add a check into each method as a first line , something like

if $this.%ClassName(1)'="My.Class" quit $$$ERROR(50000,"don't extend this class")

Since all code will be deployed, developers will not be able to remove this check easily.

You can also try to add a method-generator, I believe when you have a deployed class with method generator it will not be able to compile a subclass without method generator's source (though I'm not sure).

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