331–339 of 339 posts
Please. Reduction to absurdity isn't a valid argument. Are those folks working at large scales? Are they tuning DB's for applications which have to handle hundreds of thousands or millions of transactions per second? I don't imagine you actually know what you're talking about here.
Dunning-Kruger right here folks.
Earlier quoted context omitted.
Maybe in 5-10 years I'll consider taking a look at containers. Currently, they are a fad not much unlike React.
Hmm, why do you think they're a fad? Virtualization as a way of controlling specific application environments has been around for decades. The current movement (kicked off by the hypervisor work over a decade ago) is towards running more virtualized environments now that hardware and software support is much better (reduced overhead associated with it, greater portability). Do you mean that they're overused or that t…
We will see if Docker and other container technologies will get their hold in industries other than startups. For now, all the people who use it that I see are the cool kids on the block in their hoodies. I think boring technology is good technology in that it provides value and stability for everyone. I am yet to hear of one Docker adoption where at scale the company saved more than a three digit sum year-on-year. Remember that you also pay an extra for sysops folks who run these things, and they will ask a higher price because the tech is hip!
For me, I'll stick to VmWare and kvm for now.
I get where the guy is coming from, I'm right there as an old guy. On the other hand, I think there is a bit too much fatalism in the article. Sometimes the kids are being stupid, and they need to be told so. The vast majority of web apps could be built in 1/10th the code with server-side rendering and intercooler.js. All this client-side crap is wasted when you are trying to get text from computer A into data-store…
I didn't know intercooler existed, so thanks for the link. For anyone else, it's worth reading about, it actually has a very well written introduction, guide and examples.
Earlier quoted context omitted.
I didn't know intercooler existed, so thanks for the link. For anyone else, it's worth reading about, it actually has a very well written introduction, guide and examples.
Yep, the docs are very good, and I've been enjoying catching up on the blog archives, too, for interesting project background and philosophy.
Earlier quoted context omitted.
A little past 50 here. I can relate. Yet some things have barely changed. Beyond 25 years ago it was Solaris or HPUX, using C, talking TCP/IP and mucking about with SQL. Some of us were sad at SVR4 as we still preferred the BSD view of things. Running Unix and 10 terminals on some 680x0, learning to get efficient in vi. Some preferred emacs. I was excited for the future, especially of hardware and the OS, as I'd seen…
What about applying concurrency to more problems? So many of the basic ideas were discovered and tried a long time ago, but widespread application of concurrency still hasn't caught on.
Earlier quoted context omitted.
I work on navigation software ( http://project-osrm.org/ ). Many of the algorithms we're implementing (or at least considering) only exist in recently published papers, or sit behind unpublished APIs. There have been huge improvements in graph route-finding algorithms in the last decade, so much of it is new, interesting and it's far from run-of-the-mill implementation. I'm 38 - I spent the first many years of my car…
>> backend, specialized algorithm implementation Sounds great - how does one go about finding that sort of work in the industry?
Earlier quoted context omitted.
Well, I learned to code in order to do bioinformatics. I didn't start out as a programmer looking to specialize. I agree that it seems that programming + X is often a much more powerful combination than programming or X alone. But I would say to anyone starting out that it is better to head towards, and get the formal qualifications for X, and learn programming on the side (or if in college, get the major in X and a…
Thanks xaa for your thoughtful comments. I've taken a few MOOC on Bioinformatics. Biology certain seems much harder to get feedback esp. if you work in the wet lab, but I'm curious however about what particulars in Bioinformatics in your opinion is harder to learn (assuming that a computer person has taken Biology 101, aware of DNA to RNA, transcription, translation, mutations, variants, alleles, genotypes, haplotype…
Yes, this is it. You are right that the really general basic concepts (what is DNA? how does transcription work?) are not all that hard to learn. And it is certainly part of the core job skills to know, e.g., how to process sequencing data and how to use statistics. But in the real world, bioinformaticians work in collaboration with wet-lab biologists.
So, a typical project for me might look like this: collaborator comes in and tells me that his lab studies a particular protein X that operates at the presynaptic terminal in neurons. And they are collecting data about how some perturbation to X affects other cellular systems. The data will often be some combination of sequencing/array data and more specific wet-lab experiments (western blots, electrophysiology, etc).
So, in that case, to really do my job well, I have to go back and read in depth about the presynaptic interface, the major proteins and the mechanisms that work there. I may already know the generalities, but to really be able to interpret the data correctly, I need to know the details.
Now, imagine doing this process 10-20X a year for different collaborations and totally different biological systems. It's very hard to keep up. Now, it is certainly possible to be the kind of bioinformatician who is "give me your sequencing data and I'll give you the DE genes back", treating everything as a purely technical problem. But these kinds of bioinformaticians are not as much sought after because the wet-lab biologist doesn't want Excel spreadsheets full of lists, they really want to know "what do my results mean?". And to answer that really requires both the bioinformatician and the wet-lab biologist to understand what the other is doing at a more than superficial level.
In short, the hard part isn't learning the things that are used in every project, the hard part is learning the domain-specific information that is relevant to each individual project.