Roku Developer Program

[coskel]

I've been on this board for about a year, and have noticed something I will call
"troubling" for lack of a better term.

And that is a noticeable LACK of support from the community TO the community.

Look at the homepage of the Roku Developer Program.
Look at the threads, and how FEW replies each one gets, if any.
Sure some threads have replies, and some users get the help they are looking for, and some members provide help.

When threads go weeks/months with no answer, when there are thousands of working Roku channels and lots of members in this community?
It certainly isn't because of a lack of knowledge.

I noticed this because I am also on the vMix, JW Player, DCWW and SAM forums (on SAM I go back to 2006) and although it may take a few days, people actually assist one another with development. When I started coding back in 96, that is what it was like. What is has always been like.
Developers share code (unless of course its proprietary software), they QA each others apps, etc etc etc.

Personally I try to answer what I can, but my BrightScript skills are too basic to be of much help.

Not posting this to start a flame war, just making an observation.

[EnTerr]

Dude!
I have been on Roku's forums for 5 years and have over 2000 posts, 3/4 of which in the developer forum - most of these are trying to address some specific problem. I am not sure what more humanly possible i personally can do, short of fielding questions full-time. And i am not even the most helpful one around.

The fact is, for Roku development this is the place. StackOverflow is 1/100 the odds. Did you know that Roku Co has people on staff with title "developer evangelist", which have never showed up here nor done any evangelization (meaning, in public view)? That is because somebody at the Co does not know the difference between "evangelist", "advocate" and "private confessional". On the other hand there are a few Roku engineers that show up here out of good heart (no work credit), i gather - praise be upon them.

Don't offend your fellow developers because they are your next best hope. I can give you couple of tips though:

• When posting, try to summarize in the thread topic/subject the question^. Yes, "just an observation..." is a click-bait in case i was browsing bored but not if i am scanning the topic page. I clicked on it because i recognized your name from a PM, otherwise wouldn't have.


• Give some time to the forum for response, like say a week (i have seen people bouncing up and down because they did not get reply within couple of hours). Then if time passes and topic goes off first page with no traction, post a follow-up reply - maybe you found out something new or just bumping it.

(^) imagine you are asking the question to the currently un-manned twitter @RokuDev

[coskel]

UGH I hope I didn't offend, thats why I worded my post carefully as an observation.

Obviously every forum will be different, I was just surprised to see the number of unanswered posts...
I think the bigger issue is that because BrightScript is a language that is only for Roku development, it makes it difficult for questions to get answered by laypeople (non-Roku employees).
Most other development environments are using languages that can be taught elsewhere
- books, courses, online tutorials, etc.

BrightScript exists nowhere outside of this environment, and its not documented from a USER perspective.
Yes, the documentation gives definitions, but little in the way of examples.
Yes, there are example files, and those have limited commenting.

Obviously people are figuring out solutions, but it doesn't get in the documentation or the examples.
I wish I were better at BrightScript, then I would offer to update documentation myself.

As is it, I have decided every time I am in the forum I will try to answer a question that is within my knowledge base, and maybe others will do the same.

[EnTerr]

The issue is not with BrightScript as a language but with the API (objects and methods) being under-baked and under-documented (sometimes flat out undocumented). Plus lack of examples. Plus the existing examples being sucky and newbies thinking they could just sub their MRSS URL and ship. Random recent case, the touted "SThree" graphic scene example (hint: disconnect network, now try running it, rejoyce).

B/S (short for BrightScript in my parlance, not to be confused with B.S.) is fairly decent scripting dialect of BASIC. It's quirky for sure - but there are also good ideas i haven't seen in other languages. If you knew another scripting language (Python, Lua, Javascript, Perl, VB script), you get running start. Ditto if you once knew BASIC.

[coskel]

"EnTerr" wrote:
The issue is not with BrightScript as a language but with the API (objects and methods) being under-baked and under-documented (sometimes flat out undocumented).

THIS ALL DAY. 😉

"EnTerr" wrote:
Plus lack of examples. Plus the existing examples being sucky and newbies thinking they could just sub their MRSS URL and ship. Random recent case, the touted "SThree" graphic scene example (hint: disconnect network, now try running it, rejoyce).

Or the SThree video grid example which is my current headache. Since most folks doing streaming are using Wowza, Flash Media Server, or some other flavor of streaming that supports HLS, Silverlight, Mpeg-Dash, etc. on a specific port and a player such as JW or Flowplayer that uses an m3u or a smil file, why oh WHY
does the example force a hard-coded URL in the xml file???

See my post about media:content. streamUrl is so much better than the way it is setup now.

"EnTerr" wrote:
B/S (short for BrightScript in my parlance, not to be confused with B.S.) is fairly decent scripting dialect of BASIC. It's quirky for sure - but there are also good ideas i haven't seen in other languages. If you knew another scripting language (Python, Lua, Javascript, Perl, VB script), you get running start. Ditto if you once knew BASIC.

Well, I know PHP, and enough Javascript to get me in trouble. I took one BASIC class in 1983, which might make me an advanced n00b.

[adamkaz]

The issue is not with BrightScript as a language but with the API (objects and methods) being under-baked and under-documented (sometimes flat out undocumented).

😄 And sometimes completely incorrect! The statement that applications must be less than 2MB led me on a waste of time trying to compress a FHD image way down, only to have people on the forum tell me it's an outdated requirement. (https://sdkdocs.roku.com/display/sdkdoc ... alkthrough). Even when you compile an application bigger than 2MB, you get a scary warning about it not working on Roku 1. (they mean the 1st generation Roku devices - don't get me started on supporting customers who complain a channel is not working on a Roku 2, which could mean 1 of 5 different models)

[Tyler_Smith]

I just found a case on https://sdkdocs.roku.com/display/sdkdoc/RowList where they indicate that rowItemSize accepts an array of vector2d items, so I planned my entire workflow for a feature around this, only to find out it only accepts a single vector2d. I feel your pain.

Anyone know if there is a formal way to report these inconsistencies?

[coskel]

My thought was to start correcting it, commenting the code, and submitting it, almost like a user-generated SDK and set of examples.
A "BrightScript for Dummies" type of alternate document and set of examples.

[BCVatOVG]

Not to move away from the Roku Forums, but for this developer forum, I think it would make more sense and get better traction as well as make developers more likely to ask and answer better questions if we could set up a Stack Exchange type Roku Developer site.

http://area51.stackexchange.com/faq

We just need to get some traction and possibly get Roku on board.

[BCVatOVG]

Once I propose a site, what happens next?
A site goes through several phases before it launches to the public. Each stage is designed to improve the site and build up momentum and support.

1. Interested parties propose and discuss sample questions to define what the site is — and is not — about.


2. Users are asked to commit to participate in the site to assure that the site will have enough participation — we don't want to create ghost towns.


3. The site is launched for a beta period to seed it with questions, develop the FAQ, appoint temporary moderators, and refine its design.


4. If a site reaches critical mass, it becomes a full member of the Stack Exchange Network.

If a proposal loses momentum, it may be re-evaluated or merged with similar proposals. Inactive proposals that do not receive any activity for one month may be deleted. Deleted proposals can be re-proposed anew by users with renewed energy and, hopefully, better resources to bring it to commitment.