大学の授業では理論的な基盤を教えることが多く、実務的な知識はあまり教えないのが普通である。 しかし実際に研究・実験・就職をする場面になると、学校では教えない多くの知識が必要になる。 残念ながら、現在の大学にはこれらを体系的に教えるようなカリキュラムは存在せず、多くの学生は独学か、研究室の先輩などから教わることになる。 ここではそうした知識のうち重要と思われるものを記した。なお、プログラミング言語や業務システムに関する知識は除いてある。 また、知識は「○○を勉強せよ」などという漠然とした指示ではなく、できるだけ具体的な例を挙げた。
もちろん、これらに加えて大学の授業 (線型代数、アルゴリズム、統計、型理論など) も きちんと学ぶ必要がある。 企業などでは実践的な知識がなければ「使えない人」とみなされてしまうが、
Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.
Wayland proponents make it seem like Wayland is "the successor" of Xorg, when in fact it is not. It is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incompr
futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.
I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.
In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.
For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.
If you're interested in learning more ab
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
With the release of Node 6.0.0, the surface of code that needs transpilation to use ES6 features has been reduced very dramatically.
This is what my current workflow looks like to set up a minimalistic and fast microservice using micro and async + await.
| # 「Redmineチューニングの実際と限界」 | |
| # グラフやベンチマークはスライドシェアにあります https://goo.gl/VDSX9N | |
| # 本稿で扱った性能ベンチ－マークは下記設定による。 | |
| # Setting_paramaters_for_Redmine_Performance_Tuning | |
| # Description, benchmark graph slides at Slideshare: https://goo.gl/VDSX9N | |
| # WARNING: | |
| # No warranty, No support. | |
| # You can use these settings at your own risk. |
| diff --git a/usr.bin/doas/Makefile b/usr.bin/doas/Makefile | |
| index 809fe0b..6610edb 100644 | |
| --- a/usr.bin/doas/Makefile | |
| +++ b/usr.bin/doas/Makefile | |
| @@ -1,14 +1,31 @@ | |
| +# $NetBSD$ | |
| # $OpenBSD: Makefile,v 1.1 2015/07/16 20:44:21 tedu Exp $ | |
| -SRCS= parse.y doas.c | |
| +.include <bsd.own.mk> |
| pacman -S wget # needed for debootstrap | |
| curl -o /tmp/db.deb http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.60~bpo70+1_all.deb | |
| mkdir /opt/debootstrap | |
| cd /opt/debootstrap | |
| ar x /tmp/db.deb | |
| tar xf data.tar.gz | |
| mkdir /opt/debian |
Many of us use the OverloadedStrings language extension on a regular basis. It provides the ability to keep the ease-of-use of string literal syntax, while getting the performance and correctness advantages of specialized datatypes like ByteString and Text. I think we can get the same kind of benefit by allowing another literal syntax to be overloaded, namely lists.
The simplest example I can think of is allowing easier usage of Vector:
[1, 2, 3] :: Vector Int
In order to allow this, we could use a typeclass approach similar to how OverloadedStrings works: