Hey guys!
Background info: I am trying to use LiveBook to create some Elixir practice problems. I’d like the user to be able to enter their answer into an elixir cell, then I check their answer by running a test on their code (hidden so they can’t see it).
See this pic for what a practice problem might look like: Practice Problem
Question: I just tried using “Deploy as App” in LiveBook and it solves the problem of needing to hide code from the end-user. However, “deploy as app” actually hides too much.
I want the user to be able to write into an elixir cell. But I can’t find any way to get an elixir cell to display in a deployed LiveBook app. I looked into both Kino.Frame and Kino.Input. Did I miss something?
If this capability does not exist yet, is it possible to add a feature to LiveBook where we could set a flag to tell LiveBook which particular elixir cells on a page we want hidden upon ‘deploy to app’ instead of it automatically hiding all of them?
Hey @lmletham! Apps serve a different purpose, their source code (cells) never changes. Learning materials are better as plain notebooks, so the user can edit and evaluate the code, having access to all the intellisense features.
You can use modules with doctests and tell the user to implement a function, Livebook automatically runs doctests. You can also define whole test suites using ExUnit. You can use the <details> tag in Markdown cells to offer example solutions or tips. You can see curriculum/exercises at main · DockYard-Academy/curriculum · GitHub for examples.
Thanks for the feedback! Good to know that apps were not exactly for the use case I was thinking they were.
I’m not sure I fully agree that learning materials are better as plain notebooks. I think it may depend on the target audience. Someone who knows what they’re doing programming-wise, it is totally fine. But I’ve done some pretty extensive playing around in Livebook and I’d say that for true beginners (people experiencing code for the first time) it is definitely not ideal. Of course the beginner must still have some ability to edit and run the code, but that there is plenty of stuff you want hidden or locked down.
Some issues:
- Doctests are great, but sometimes they reveal just a little bit too much if you’re going for more of a practice problem scenario. I may ask a beginner to write a function as simple as addition or subtraction. The doctest instantly gives away what to do, plus it makes the code look more complicated (to new eyes). I’d love it if I could have all testing code hidden from the user.
- Another problem is that the markdown in a regular notebook is editable. I don’t necessarily want a user to accidentally delete an explanatory markdown cell. They shouldn’t even have the option to make that mistake.
- There are ways to hide code cells in Livebook, Brooklin wrote a smartcell to do so for the Dockyard Curriculum you referenced, and I’ve tried it out, but sometimes it is a huge pain to work with. I may write code in the cell and want most of it hidden (but one or two bits to be displayed to the user). The problem is that when a new user first opens Livebook they have to run the hidden cells before those things will display. Having tested this out with a few beginners they found this really confusing.
So I guess that for my target audience I’d say it would be ideal to have a bit more control over which cells do or do not display to the user when “deploying as an app”. If there’s any appetite for trying to set something up that allows for this in LiveBook let me know, otherwise I may try to write a smartcell to do what I need.
The thing about apps is that by design we don’t want to show code cells. The app source code is “fixed” and the user interacts with the app via the rendered UI (inputs, custom elements, etc). In that case the notebook is basically source code and the app is a running program.
Technically you could build an app where the user types into a text field (or rather some custom editor), and then have a button to run tests. It would be up to you to evaluate the user’s code and test it. However, with this approach (a) the user needs to actually deploy the app, so it only makes things simpler if you host the app rather than users working with the materials locally; (b) the custom editor within the app is not going to have the intellisense features, like completion and documentations, which are crucial for beginners.
I may ask a beginner to write a function as simple as addition or subtraction. The doctest instantly gives away what to do
The doctests would be just an input/output assertion, so I wouldn’t say it gives away anything about the solution.
If empirically the target audience is confused with some aspects of notebooks, perhaps it would make sense to have a short video or text tutorial that outlines the basic idea of a notebook and how to run the code. But that’s specific to the users and the use case : )
