Talk:Scripting Certification

Overlapping categories

There is a bit of overlap between the categories. Do we want to rework the categories or just go with it? -- Strife Onizuka 18:46, 24 April 2007 (PDT)

Difficulty

The way this is shaping up, it will be a difficult certification. -- Strife Onizuka 19:50, 24 April 2007 (PDT)

We need to specify the core skills the should be 75% of the test (ie. understanding events, if statements) the other 25% could be the lessed used functions/techniques (ie. using external scripting tools)--Destiny Niles 16:50, 25 April 2007 (PDT)

I'm uneasy about dumbing down the certification so the lowest common denominator of scripter can pass with no work. I really think the Certification should be used as a catalyst for scripting education. The test should be split up into 4 to 12 sections, you don't need to get all the questions in a section right (each section is specially tweaked for number wrong that is acceptable). My reasoning for this would be so that important sections could be stressed and less important sections could have a reduced impact. I'll expound upon my thoughts on how the scoring will work tomorrow (don't worry it takes your comment on weight into consideration). -- Strife Onizuka 17:40, 25 April 2007 (PDT)

I'll be sad to find that I won't be able to get scripting certification because there are great gaps in my core competencies. However . . . when it comes to a certification that is supposed to help me figure out who's qualified to work for my company, I don't want to see this test be something easy. I'd like this to be a test that makes it clear if someone is a programmer with a professional-level competency in lsl. So I'm thinking of it as a test comparable to one you'd give a programmer to test how well they can use some other programming language professionally. What would be included in a test of, say, C programming?

Thanks for your patience, btw . . . I'm not really that much of a scripter and feel I'm in a little bit over my head here, but I wanted to get in a few comments from the perspective of someone who hires lsl programmers. :)

--Kim Anubis 10:12, 28 April 2007 (PDT)

The core certification (atm) is to set a base level of skills. It's not a difficult certification, it's just requires the applicant to know the information. The part that will be the hardest will the the Caveats sections. The rest of the certification is to test your knowledge and ability to use the language. It isn't testing application of those skills (except for asset permissions, which will have a lab where the applicant will have to transfer a script and set proper permission on it before doing so). If you have a basic grasp of LSL then studying for the Core won't be hard. Speaking of which, we need to make study guides for it. -- Strife Onizuka 09:20, 30 April 2007 (PDT)

Maintenance

It dawns on me that LibSL could be used to be the guinea pig and grader for tests. Having scripts being graded automatically would drastically reduce the cost of maintaining the certification program. -- Strife Onizuka 17:40, 25 April 2007 (PDT)

I'm not quite seeing this. Could you expand? --Ordinal Malaprop 15:41, 26 April 2007 (PDT)

Well the questions that aren't multiple choice would require the use to write scripts, those scripts would need to be graded. Easiest way of testing a script would be to plug it into SL, LibSL can fill that roll. -- Strife Onizuka 18:07, 26 April 2007 (PDT)

The script running is not the only test factor. ie. is see "if" statements being used incorrectely all the time - they may work but they are still incorrect. Good programming is also a factor. --Destiny Niles 08:34, 3 May 2007 (PDT)

I am not at all convinced that, apart from rudimentary checks, libsl, or any other kind of automated tool will produce valuable information on the quality or grade of scripts. Yes, you could check for some poor design patterns, but anything beyond the simplest tests (use of deprecated functions, as an example) runs the danger of producing both false negatives and false positives. Take for example a test to check excessive use of sensors or listeners. If you are talking about an animation HUD compared to a weapon you have widely different criteria as to what "excessive" means; also design patterns and practices change as work-arounds are found and the very fabric of SL changes. Automated evaluation tools will quickly become an encumberance rather than an aid to objective evaluation. I propose a more best-practices model, where a scripter has to demonstrate to a knowledgable examiner, the techniques they have used and the justifications for them. --Lexx Greatrex 13:42, 3 May 2007 (PDT)

The advantage of an automated grading tool is that it is cheep to run. Having a knowledgeable instructor on call would probably require the movement of a large chunk of money. Your points about the need of different grading criteria for each question are valid. I don't see the problem though, a well built grading program should be able to be configured for each question with the appropriate criteria. As you point out, it doesn't make sense to grade everything with the same criteria. -- Strife Onizuka 17:50, 3 May 2007 (PDT)

The disadvantage, though, is that it just can't do the job. I would love to see an automated tool which could even _read_ code properly. I'm afraid I don't see how any sort of automated examiner, libsl or otherwise, could actually examine scripts in themselves. A parser is probably about the limit that we could ever do; further than that, questions will have to be limited to specific examples rather than whole scripts, or involve actual examiners. --Ordinal Malaprop 16:48, 4 May 2007 (PDT)

Units

I'm looking at the current list of sections (aka units) in the list presently, and wonder whether it is right that a certificate should be an 'all or nothing' approach like this. Speaking as someone with minimal interest in scripting vehicles - and I'm sure similar considerations apply to others - a structure of "Scripting" with subsudiary units of "avatar", "vehicle", "building-related", etc. might be a preferable route to take. --AlisonW 05:50, 26 April 2007 (PDT)

Yes, I was just thinking that, a lot of these functions are important for some people but pointless for others. Vehicle builders don't need to know how to make networked vendors and vice versa. There are general skills such as list manipulation and use of link message which are broadly relevant but most people specialise to a reasonable degree after that. Core skills need to be identified. --Ordinal Malaprop 05:58, 26 April 2007 (PDT)

This has been nagging at me as well. Maybe the certification should have optional subparts? Or maybe specialized areas should have specialized scripting certifications? I'm inclined to go with specialized certifications. But at the root of this, we have the question: What is the goal of certifying scripters? Are we marking people as Gurus or something else? Strife Onizuka 06:16, 26 April 2007 (PDT)

I had always assumed that the certification would be divided into different categories, and with different levels. The introduction on the article gives the impression that it is one certificate testing all aspects of scripting at the highest level. As Strife Onizuka mentioned, this would just identify gurus, and I'd be surprised if more than a handful of people could pass a test like that; plus it could take half a day to complete.

As people have hinted at, I would go along with a core LSL certification of the most fundamental skills (list manipulation, communication etc.), and smaller specialisations. The core exam would be completed first, and then as many or as few of the specialised ones as desired. I'd also propose 2 levels of complexity - intermediate and advanced. Certifying basic skills, especially if it costs to do so, is unnecessary.

--Lucius Nesterov 07:17, 26 April 2007 (PDT)

I've juggled the topics into certifications, I'm still not happy with it, some certifications don't feel right yet. I'm thinking of merging the Attachment certification into the other certifications (like Permissions and UI design). -- Strife Onizuka 14:33, 26 April 2007 (PDT)

Attachments are a tough one - there's a lot of calls and a few events that work differently in attachments, and then there's all the special cases around HUDs. --Storm Thunders 06:05, 27 April 2007 (PDT)

Good point, maybe there does need to be a cert for attachments. -- Strife Onizuka 06:48, 27 April 2007 (PDT)

I would like to see something included about commenting code and writing documentation good enough for in-house use. Modelers (or whoever else is assembling the components of an object) should not have difficulty adding the scripts to objects (they need to know about required link order, what script goes in what prim, if certain prims need to have specific names, etc.), the tech writer needs to have a basis for the documentation for the client/end user, and it should be easy for other programmers to readily understand what the code is doing so they can modify it.

--Kim Anubis 10:15, 28 April 2007 (PDT)

I've made some additions to the Core Cert, Documentation Styles & Commenting to Syntax/Logic section. -- Strife Onizuka 08:40, 30 April 2007 (PDT)

Strife, I commended you on the work you've done so far. However, I'd suggest one intermediate scripting cert. External communication and physics could be included in the advanced (specialisations) of Database scripting and Vehicles respectively. Maybe some other categories could be moved to specialisations as well. I hinted at this before, but I'll just lay it out formally.

• Core-Intermediate: Communication, states, type conversion, gaining permissions, properties etc.
• Core-Advanced: Sensing, inventory manipulation, animation, using permissions, script updates etc.
• Specialisations:
  • Applied animation: Co-ordinated linked anims, particles systems, texture anims etc
  • Vehicles: Vehicle types, integrated HUDs, physics etc
  • Database scripting: External communication etc

You seemed to be getting lonely here, so I thought I'd add some debate. --Lucius Nesterov 04:58, 3 May 2007 (PDT)

The problem I have with that is that you don't need Sensing to be a specialist in Databases or Vehicles or Applied Animation. I think Sensing should still be an intermediate level certification but not part of the core. Moving physics into vehicles isn't really appropriate, there are uses for physics other than vehicles (there are physics functions you are not supposed to use on vehicles!). I think an intermediate Core is probably a good idea. I'll start pounding together the sections. -- Strife Onizuka 06:32, 3 May 2007 (PDT)

I'll defer to your judgement. There are whole sections of lsl I've never used so it would be difficult for me to judge their relative complexities. However, although the current arrangement is logical, I get the impression that some of the proposed certs are a little light on content. Looking at the bigger picture, if different areas of SL become certified (modelling, gestures, event management, etc), each with several sub-category certs, then a cert in say advanced particle systems seems even smaller.

Now may not be the time, but it might be worth considering in the future to create just a few big certs in addition to the cores. For example group 'detection and sensing' with 'Agent Interaction/UI' in some 'Responsive scripting' cert; or group 'Physical and Non-Physical Movement', 'Vehicles' and maybe 'Particle Systems' into a 'Dynamic scripting' cert. There are of course a mix of skills in each, and some parts may be redundent for certain people, but.. I'm having a hard time trying to describe why I think it's better, other than 'less is more'. Meatier certs might have more value?

--Lucius Nesterov 03:18, 8 May 2007 (PDT)

I've noticed that non-physical in vehicles shouldn't be there since a vehicle alone can't be non-physical. (vehicle params/flags requires physic) However, I know there's a large moving ship that is non-physcial but never ruled out as a vehicle in my term since it never use any actual physic to the work. Some vehicles (cars, bikes, planes, boats) do often use non-physic state for debunking such condition to be a physical object again. People would need to keep in mind that those large non-physical ships DO NOT rules out as a vehicle in SL. Even though, it shouldn't matter as much since they hardly move much and people used them as stationary home. I'll fill in some importance topic to general physical vehicle to the list. (Funny thing is, most car builders would fail at this point since DT scripts has been used widely.) --Vincent Nacon 07:18, 17 August 2007 (PDT)

Efficiency and Performance Tuning

I firmly believe that the certification should have emphasis on efficient programming techniques. Our code runs in a tiny memory space (16K) and even a simple script can have a huge impact on performance. I have also been unable to find a coherent source of information on performance tuning scripts.--Curious Rousselot 10:40, 11 May 2007 (PDT)

That would be the "LSL Caveats/Constraints" section of the Core certification. Please feel free to add to that section on Scripting_Certification/Core/Basic. The study guides are a way to for us to design what is going to be on the tests and provide a resource so people know what is going to be on the test. I'm not really sure if optimizing code should be in the Core:Basic certification, probably should be in Core:Intermediate. -- Strife Onizuka 13:14, 11 May 2007 (PDT)

I had a look. I agree that some of what is listed in "LSL Caveats/Constraints" should be in Core:Intermediate. BUT most of what is in there isn't what I'm talking about for efficient programming. I believe there needs to be way more coverage on writing efficient fast code. Things like:

• when to use for loops vs while loops (which is less byte code, which runs faster).
• Is it better to apply a texture by UUID or name?
• Is llInstantMessage(llGetOwner(), ...); better or worse than llOwnerSay(...);?
• Or even is it better to write:

string owner = llGetOwner();

llInstantMessage(owner, ...);

I have found the answer to some but not all of these. In a system where the scripts have such limited resources as lsl (and they need to in order for everything to work) these sorts of things become very important. Especially in a script rich environment. Curious Rousselot