recentpopularlog in

kme : programming   1257

« earlier  
Why would a python programmer learn rust when there are no jobs in it - YouTube
That is the coolest shirt I've ever seen. Please someone tell me where I can buy that, and port it to a vim color theme
rust  devel  programming  conference  talk 
october 2019 by kme
I used Elm in production and it cost me my job – Annaia Berry - YouTube
Time to bill the functionality not the time spent.

Once upon a time, a cargo ship was not starting. Everything seemed fine to mechanics, but the engine just wouldn't start.
After weeks of immobilization and dozen of hours of costly experts not finding the solution, the ship owners were directed by one of the experts to an old retired mechanic who supposedly worked magic in his days. The owners went for it, because at that point they would have hired a shaman if he had promised them to fix their ship.
The old guy came with his own toolbox. Within ten minutes he took out a little hammer and gently hit a specific point in the engine, which then consented to fire up.
The ship owners were delighted and asked the guy to send them the bill. On the morrow he came back with a single-line $10,000 bill. They told the old mechanic that it seemed disproportionate for the time he spent. The mechanics then rewrote the bill as such :
- poking with a hammer : $2
- knowing where to poke : $9,998
elm  haskell  devel  programming  makingyourselfdispensable  video  conference  talk 
october 2019 by kme
Quick: An Introduction to Racket with Pictures
This tutorial provides a brief introduction to the Racket programming language by using one of its picture-drawing libraries. Even if you don’t intend to use Racket for your artistic endeavours, the picture library supports interesting and enlightening examples. After all, a picture is worth five hundred “hello world”s.
racket  scheme  intro  tutorial  cs  programming 
october 2019 by kme
Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development)
"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis
antipatterns  coding  programming  career  advice  tipsandtricks 
june 2019 by kme
GitHub - tree-sitter/tree-sitter: An incremental parsing system for programming tools
An incremental parsing system for programming tools - tree-sitter/tree-sitter
programming  language  parser  library 
june 2019 by kme
BubbleSort Zines
Zines about computer science! Each zine focuses on one concept & is filled with comics, diagrams, stories, examples, and exercises.
cs  code  art  devel  programming  reference  newbie  zine 
june 2019 by kme
GAMES MADE QUICK??? 2.0 - itch.io
A game jam from 2018-01-07 to 2018-01-15 hosted by eevee. >>> ✨ 🚨 Discord ✨ 🚨 <<< Hey, you. Yeah, you. I see you there. Settling down with your popcorn and snacks. "I won't watch GDQ all week,&q
python  pygame  gaming  devel  programming 
june 2019 by kme
The End Of Object Inheritance & The Beginning Of A New Modularity - YouTube
1. use types for nouns
2. express code relationships structurally
3. most programming is parametric ("partial") programming

Advice:
* make illegal states unrepresentable (Yaron Minsky)
* ==> make illegal behavioral interactions impossible
devel  design  programming  oop  inheritance  composition  video  python  modularity 
june 2019 by kme
STHDA - Home | http://www.sthda.com/
STHDA is a web site for statistical data analysis and data visualization using R software. It provides many R programming tutorials easy to follow.
stats  visualization  r  language  programming  newbie  tutorial  reference 
march 2019 by kme
The role of instructors in teaching programming — Python for Biologists | https://pythonforbiologists.com/
This is another aspect of programming that experience tends to render invisible: when you encounter a roadblock in programming and need to ask for help, very often it's difficult to know how to phrase the question. The lack of understanding that causes the student to need help in the first place also ensures that they're unlikely to know what question to ask, or the right way to phrase it.

Of course, later on in the learning process it usually becomes clear how mindblowingly useful programming is (and I purposefully structure my courses to get students to this point sooner rather than later). Nevertheless, one of the biggest problems many students have when learning programming is simply running out of steam and becoming demoralized – a process that is usually triggered by encountering yet another roadblock.
programming  teaching  learning  computing  workshop  advice  bestpractices 
february 2019 by kme
The Unix Shell: Instructor Notes | https://swcarpentry.github.io/
Many people have questioned whether we should still teach the shell. After all, anyone who wants to rename several thousand data files can easily do so interactively in the Python interpreter, and anyone who’s doing serious data analysis is probably going to do most of their work inside the IPython Notebook or R Studio. So why teach the shell?

The first answer is, “Because so much else depends on it.” Installing software, configuring your default editor, and controlling remote machines frequently assume a basic familiarity with the shell, and with related ideas like standard input and output. Many tools also use its terminology (for example, the %ls and %cd magic commands in IPython).

The second answer is, “Because it’s an easy way to introduce some fundamental ideas about how to use computers.” As we teach people how to use the Unix shell, we teach them that they should get the computer to repeat things (via tab completion, ! followed by a command number, and for loops) rather than repeating things themselves. We also teach them to take things they’ve discovered they do frequently and save them for later re-use (via shell scripts), to give things sensible names, and to write a little bit of documentation (like comment at the top of shell scripts) to make their future selves’ lives better.

The third answer is, “Because it enables use of many domain-specific tools and compute resources researchers cannot access otherwise.” Familiarity with the shell is very useful for remote accessing machines, using high-performance computing infrastructure, and running new specialist tools in many disciplines. We do not teach HPC or domain-specific skills here but lay the groundwork for further development of these skills. In particular, understanding the syntax of commands, flags, and help systems is useful for domain specific tools and understanding the file system (and how to navigate it) is useful for remote access.

Finally, and perhaps most importantly, teaching people the shell lets us teach them to think about programming in terms of function composition. In the case of the shell, this takes the form of pipelines rather than nested function calls, but the core idea of “small pieces, loosely joined” is the same.

Installing Bash and a reasonable set of Unix commands on Windows always involves some fiddling and frustration. Please see the latest set of installation guidelines for advice, and try it out yourself before teaching a class.

Tab completion sounds like a small thing: it isn’t. Re-running old commands using !123 or !wc isn’t a small thing either, and neither are wildcard expansion and for loops. Each one is an opportunity to repeat one of the big ideas of Software Carpentry: if the computer can repeat it, some programmer somewhere will almost certainly have built some way for the computer to repeat it.

Building up a pipeline with four or five stages, then putting it in a shell script for re-use and calling that script inside a for loop, is a great opportunity to show how “seven plus or minus two” connects to programming. Once we have figured out how to do something moderately complicated, we make it re-usable and give it a name so that it only takes up one slot in working memory rather than several. It is also a good opportunity to talk about exploratory programming: rather than designing a program up front, we can do a few useful things and then retroactively decide which are worth encapsulating for future re-use.
shellscripting  unix  linux  shell  bash  butwhy  programming  sevenplusorminustwo  teaching  workshop  reference  advice  bestpractices 
february 2019 by kme
A Spellchecker Used to Be a Major Feat of Software Engineering
Writing a spellchecker in the mid-1980s was a hard problem. Programmers came up with some impressive data compression methods in response to the spellchecker challenge. Likewise there were some very clever data structures for quickly finding words in a compressed dictionary. This was a problem that could take months of focused effort to work out a solution to. (And, for the record, reducing the size of the dictionary from 200,000+ to 50,000 or even 20,000 words was a reasonable option, but even that doesn't leave the door open for a naive approach.)

Fast forward to today. A program to load /usr/share/dict/words into a hash table is 3-5 lines of Perl or Python, depending on how terse you mind being. Looking up a word in this hash table dictionary is a trivial expression, one built into the language. And that's it. Sure, you could come up with some ways to decrease the load time or reduce the memory footprint, but that's icing and likely won't be needed. The basic implementation is so mindlessly trivial that it could be an exercise for the reader in an early chapter of any Python tutorial.

That's progress.
programming  performance  progress 
january 2019 by kme
Ternary operation - Wikipedia | https://en.wikipedia.org/
Solution for Tcl via https://en.wikipedia.org/wiki/%3F:#Tcl

<code class="language-tcl">
set x 5
set y [expr $x == 5 ? 10 : 15]
</code>
syntax  programming  dammitbrain  solution 
january 2019 by kme
The Shame of Pair Programming | Diary of a ScrumMaster | https://diaryofascrummaster.wordpress.com/
To pair requires vulnerability. It means sharing all that you know and all that you don’t know. This is hard for us. Programmers are supposed to be smart, really-crazy-smart. Most people look at what we do and say “I could never do that.” It makes us feel a bit special, gives us a sense of pride and pride creates invulnerability. I often hear stories that infer “I’ll just go and do some magic and if it takes a long time you can bet I made miracles happen”.

When done well, the shame of pairing quickly evaporates. As you start to realise that, between the stuff you know and the stuff they know, you can be twice as good; pairing becomes joyous. Together we find solutions that would be out of reach if we were alone.

Also, a shout-out to Brené Brown:
It’s hard. Pairing well takes empathy, empathy evaporates shame, allowing courage. As Brené Brown says “Vulnerability is the birthplace of Innovation, Creativity and Change”
pairing  pride  collaboration  devel  programming  pairprogramming  vulnerability 
december 2018 by kme
To Pair or Not to Pair: Pair Programming - YouTube | https://www.youtube.com/
Lady's from ThoughtWorks (https://www.thoughtworks.com/), and if that's sounds familiar, that's because they're the Selenium and GoCD people.

Benefits mentioned in the video:
1. knowledge sharing (1 + 1 > 2)
2. combines two modes of thinking: tactical (driver: local optimization), strategic (navigator: big picture)
3. reflection (on the story, value-added, effectiveness vs. # of LOC)
4. helps coder / team focus; discipline around structure of code, strategy, explain and justify choices, avoid rabbit holes
5. "I get more programming productivity" out of reducing time that I'm stuck than from increasing my speed when I'm not stuck."
6. helps practice "true" CI--code review on-the-go; more collective code ownership; >> trunk-based development

Tips:
1. don't do it for 8 hours a day
2. take breaks; it's exhausting
3. even skill levels
4. share feedback (I don't like it when ...), exchange READMEs
5. "the shame of pair programming"; requires vulnerability

Homogeneous teams feel easier, but easy is bad for performance. (ref: https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better)

The authors are saying that this idea goes against many people's intuition, and often if there's something counter-intuitive, there's a cognitive bias hidden away somewhere, right?

And the one that they're mentioning here is the "fluency heuristic," which says that we prefer information that is more easily processed, and if it's easily-processed, we think that it's more true, more right, more beautiful, and that serves us very well in a lot of situations in software development. We want readable code, easily-processable things. But I don't think that it serves us well if we think that's why we're not doing pair programming.

So, pairing feels hard, but that doesn't mean that it's not good for performance, and also it doesn't have to stay hard.

Ways to make it easier (reduce friction, conflict, anxiety):
1. get the talking going
2. active listening
3. friendly feedback
4. answer why

See also: https://www.youtube.com/watch?v=S92vVAEofes
agile  cs  programming  pairing  pairprogramming  teamwork  collaboration  communication  conference  talk  video 
december 2018 by kme
« earlier      
per page:    204080120160

Copy this bookmark:





to read