I have been learning programing since 1 year, 6+ month of that time with elixir. I think this is more like a general programing question than elixir. My current problem is being too slow.
Let me simulate what i do. I write a function and open iex shell. And i execute it and i get mostly different results than i expect. I change code and recompile(). After function works, to create another function i open browser check elixir docs and search some usefull functions to help me. And again iex... recompile(). After these i switch phoenix area. I open my app in browser and i test functions reload page(maybe i do that 20+ for each action until i get exact result) and look server logs from IO.inspect(). These are really taking too much time when i start coding somethings
What can i do to speed up some areas(tools, new aproaches etc…)?
What @kokolegorille said, if it’s part of a project you’ll need tests anyway and having them saves you using iex and recompiling. I only reach for browser to test relatively big parts of application and mostly develop with mix test
thanks @kokolegorille and @yurko .
Another thing is searching functions in docs. Do you use any kind of plugin for text editors to look up avaliable functions and store docs offline ?
iex> h Task.async
def async(fun)
@spec async((() -> any())) :: t()
Starts a task that must be awaited on.
This function spawns a process that is linked to and monitored by the caller
process. A Task struct is returned containing the relevant information.
Read the Task module documentation for more info on general usage of async/1
and async/3.
See also async/3.
def async(mod, fun, args)
@spec async(module(), atom(), [term()]) :: t()
Starts a task that must be awaited on.
A Task struct is returned containing the relevant information. Developers must
eventually call Task.await/2 or Task.yield/2 followed by Task.shutdown/2 on the
returned task.
Read the Task module documentation for more info on general usage of async/1
and async/3.
## Linking
This function spawns a process that is linked to and monitored by the caller
process. The linking part is important because it aborts the task if the parent
process dies. It also guarantees the code before async/await has the same
properties after you add the async call. For example, imagine you have this:
x = heavy_fun()
y = some_fun()
x + y
Now you want to make the heavy_fun() async:
x = Task.async(&heavy_fun/0)
y = some_fun()
Task.await(x) + y
As before, if heavy_fun/0 fails, the whole computation will fail, including the
parent process. If you don't want the task to fail then you must change the
heavy_fun/0 code in the same way you would achieve it if you didn't have the
async call. For example, to either return {:ok, val} | :error results or, in
more extreme cases, by using try/rescue. In other words, an asynchronous task
should be thought of as an extension of a process rather than a mechanism to
isolate it from all errors.
If you don't want to link the caller to the task, then you must use a
supervised task with Task.Supervisor and call Task.Supervisor.async_nolink/2.
In any case, avoid any of the following:
• Setting :trap_exit to true - trapping exits should be used only in
special circumstances as it would make your process immune to not only
exits from the task but from any other processes.
Moreover, even when trapping exits, calling await will still exit if the
task has terminated without sending its result back.
• Unlinking the task process started with async/await. If you unlink the
processes and the task does not belong to any supervisor, you may leave
dangling tasks in case the parent dies.
## Message format
The reply sent by the task will be in the format {ref, result}, where ref is
the monitor reference held by the task struct and result is the return value of
the task function.
I also use a lot of tab completion, it gives me the list of module’s functions directly from the console.
Another tip is I start a phoenix server with
$ iex -S mix phx.server
I can update code, recompile from the console and have it reload in my browser (in case of Phoenix) without ever restarting my server.
Another thing is searching functions in docs. Do you use any kind of plugin for text editors to look up avaliable functions and store docs offline ?
In spacemacs, alchemist allows to lookup any function docs under the cursor, as well as quite a few other actions like running tests, compiling, sending selected regions to iex buffer, jumping to function definitions, etc.
You’re still learning - and as such you should never stop learning. Developing software isn’t a manufacturing activity - it’s a design activity and the pace is totally different.
What you really need is more practice in “building software” and it’s debatable whether increased tool savviness will give you that.
By all means, always look to automate repetitive tasks but if that requires “learning and adopting yet another tool” think about the potential opportunity cost. Time learning yet another tool is taking time away from improving the skill of “building software”. So before adopting yet another tool: the potential benefit better be worth it.
The flip-side is that failing to commit to adopting a particular tool can be just as harmful - in the past not properly learning Brunch with Phoenix could become a potential time sink - just like adopting Vue.js or React while neglecting webpack can be a mistake.
So choose the tools that you invest time in wisely. And once you commit to one, go just a bit further than you think you need - otherwise you may not be aware of the additional benefits that the tool can give you.
(This is why I tend to prefer small tools that do one thing well (and hopefully integrate well with other orthogonal tools) - usually it doesn’t take that long to harness their full potential. “Batterys-included”/“all-in-one” tools tend to have a steeper learning curve even if you want just a small part of their functionality.)
After some “building software” practice, invest in some Hammock Driven Development - i.e. don’t let tool-use get in the way of (or worse, replace) thinking. Conversely sometimes you need to do stuff to move the thinking along - and possibly even throw away “the stuff you just did”.
Just keep in mind:
Tests are real code and as such they should adhere to the same quality standards as production code - if you are going to keep them over an extended period of time.
Don’t let the tests weigh you down. Regardless of the coding investment, delete them when it’s clear they are testing the wrong thing in the wrong place. Deleting tests can be hard; treat them as a byproduct of your knowledge acquisition process. Tests can be used to explore the solution space for a particular problem. You can easily find yourself in a position where the tests will tell you that you misunderstood the problem. The tests have done their job - now delete them and start solving the right problem in the most appropriate manner.
Speed shouldn’t be your objective, it comes with time and experience and you will be fast at certain aspects and still slow in others. I check docs countless times a day and while I know some stuff by heart most the time I just know a vague idea of the function I’m looking for or how to do it in another language. So somethings I’m fast at others slow and I’m approaching a decade of experience.
I know many programmers who are very fast but leave an awful mess in their wake. Speed is relative, I might be able to complete a feature in 2 hrs that would take a colleague 4 hrs but he might have made a more robust, extensible solution or considered things that I forgot or considered unimportant at the time. Another programmer might take 30 mins and get something quick and dirty up which will work but will be a mess that needs mopping up sooner or later.
So focus on automating repetitive tasks. If you’re checking a browser a lot and not working in html or css then you should probably be writing tests which will let you focus on the code not switching windows. I only check the browser when I’m making a visual change like color or position and I let tests tell me if the thing is displaying with the correct values when I visit that page or run a given function and I only open iex if I want to experiment with a specific function or check docs directly via command line I rarely write new code directly there.
Testing will probably be your largest leap in speed, so I’d focus on that one first when you learn to avoid context switching to a browser when you don’t have to, that’s a massive speed increase, it’ll save you 10-15 seconds of swapping and clicking around on average. Time yourself next time you switch from terminal editor to browser and refresh and check something how long is it 5 seconds 10, 20, 30? 5 seconds doesn’t seem like much but 5 * 20 is 100 so you’re losing almost 2 minutes every time you fresh the browser 20 times assuming it’s only 5 seconds and I’d bet it isn’t. Finally make sure your editor supports running tests with a simple key binding and get used to pressing it a lot it should be 1 or 2 keystrokes. That saves tons of time because you’ll be running them a lot and 1-2 seconds to click a button or type “mix test” is a lot of time over the span of a day running tests hundreads of times. Little things like that can make massive improvements to your work speed even if everything else remains your current speed.
I use Dash, which is a Mac app that stores all kinds of docs offline, lets you create documentation sets, lets you look up things from your editor, etc. If you use a Mac, I recommend it.
I agree with the other folks about tests, auto-reloading, etc., but occasionally I find it easier to have a scratch .ex file sitting around and a script or editor shortcut that executes the script. That way I can change line 3 of 20 and just hit a key to re-run. (I literally have “scratch.ex” and leave it .gitignored, and have a keyboard shortcut in my editor that is hard-coded to run that scratch.ex file.)
Others have said it and i’ll mention it again. Test Driven Development.
As you are learning how to do test driven style you will likely feel frustrated and like it’s even slower and worse than before - I can tell you now you will need to "Slow down to go faster. " Test Driven Development can help you do this. It’s an investment - however learning to write tests will take you to the next level in terms of speed and quality. It can take quite a while to become excellent. I remember still being frustrated after 5 years of BDD/TDD work - then for me there was a moment where all the hard work paid off and I looked around and saw myself blasting past others in these terms:
Writing code that is clear.
Writing less code for specific purpose
Understanding the problem clearly
No bugs in my understanding - only bugs due to not knowing what i didn’t know (best kind of bug - learning opportunity)
Understanding of layers of software
Understanding of ways to isolate software (both for testing and for design purposes)
Now i find that it is a delight to consider and create the correct test for kind of behavior i’m looking for and then discover how the code comes to support the behavior without waste or unneeded lines.
So, in the spirit of racing - focus on learning testing, focus on creating a smooth workflow - speed will be a bi-product of this.
On the topic of TDD, I do think it’s at least pointing out that in a number of cases, you can waste a lot of time doing TDD if you focus on testing every implementation.
For example, let’s say you create a bunch of low level isolated unit tests for each function you make.
That’s fine and dandy until you decide you want to create an integration test that pulls together a few things and then tests the end result of what you’re actually trying to do. Now you end up testing the same code path multiple times which is both wasteful from a productivity and run time point of view.
For example, if you have a function that calculates 2+2 then writing a unit test that it equals 4 is a total waste of a test if you happen to also have an integration test that goes through the motions of a user visiting a /calc route and submitting the form where you assert they get 4 in the response.
Both tests involve testing your calculate function and I would argue the integration test is more important here because if the calc function didn’t return 4 you wouldn’t have gotten 4 in the response.
I find the remarks that Lamport (see the citations in my previous mail) made most important to evaluate before thinking any further about TDD. I don’t use it at all as you can guess as I find it a waste of my time. More comments appeared here: BDD / TDD criticized
