Sadly, in most cases, this mean you have to decide between ugly and performant, or nice and slow code.
I hope this gets fixed soon. Nobody should have to write queries like this:
select blah blah blah
from x, (select blah blah blah
from y, (select blah blah blah
from z, (select blah blah
from w
where a=b
and c=d)
where z.id = w.id
and p = 2
and q = 4)
where z.id = y.different_id
and r = 3
and t = 'BLAH'
and u not in (select u from w)) l
where l.id = x.id
CTEs allow you to build "lisp-like" pipeline where you transform your data as you go and are able to give the intermediate results useful names.
Yup, it's a bit unfortunate, but that's how it is most of the time.
I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API.
Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented.
Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...
I'd say that ~98% (statistic pulled out of the thin air) of Single Page Applications are - in fact - Single Page Websites in your terminology. At least that's what I usually see when various companies are using Angular (or Ember, or React-with-routing, or any other library/framework) to power their web applications.
Honorable mention for the application that you probably have in mind can go towards (IMO) React UI Builder which was posted to HN a few days ago (https://github.com/ipselon/react-ui-builder).
Do you actually support 'full remote' positions?
I'm asking because the application system on your site has 'Permanent legal right to work in the United States.' listed as one of the requirements.
The platform I know best (.NET) seems to align with what you're looking for, but working in and/or moving to US is not really an option. Time zone wouldn't be an issue though.
It's something that I noticed too. I had what I think was a pretty unique opportunity to be involved in project(s) from the very beginning to the 'end' (i.e. support phase) from my early working days - since my very first year. That allowed me to fully experience writing really underengineered code, then subsequently vastly overengineered, then a chance to clean it up - all while having no one else to blame but myself for any shortcomings. I'd like to think it taught me a lot and of all the rules-of-the-thumb and catchy acronyms, it seems like KISS and YAGNI sank in the most.
Also, a lot of the points the article makes about the senior engineer seem to be about a 'business sense' - what the actual business problems you're solving are and how your solutions influence the business itself. I really like to know all that - in fact, those are my starter questions as a candidate in any job interview - but I don't know if it's just an innate trait that some people have, if it's something you pick up, or maybe both to a degree...?
And I don't consider myself a senior engineer, not by a long shot...
What 'kind' of engineer are you looking for? Any specific platforms, languages or fields of interest? I went through the site and the portfolio consists of multiple (and very different) projects, so I'm just wondering how it works. :)
We're a pretty small software consulting agency, so we're looking for engineers that are capable of learning new technologies and adopting to best-practices in those technologies.
Ideally, we're looking for people that:
* bring expertise in at least one framework that we're likely to use[1], and
* love to start projects in a software stack that they haven't used before.
I mean, I mostly work with C# and F# on the back-end, but I created my fair share of WPF apps which I vastly prefer to web front ends. I also tinker with Scala in my free time, but I don't really know much about the JVM ecosystem.
I also readily admit I know next to nothing (neither have a feeling for) the UI/UX design, which is why I usually relied on libraries like MahApps; lately I had my eye on Material Design for WPF.
Considering my contract is up soon(ish), what you're offering looks tempting. :)
All things considered, I still feel compelled to ask: do you have a salary range or is it discussed individually? Or both, to a degree?
> All things considered, I still feel compelled to ask: do you have a salary range or is it discussed individually? Or both, to a degree?
Both, to a degree. Specific salary offers are going to vary a great-deal with candidate experience. Our salary floor is $65,000 / year, and it ranges up from there. We also offer retirement and health-insurance reimbursement.
As a final bonus, you get to sign our confidentiality agreement which says that you'll keep our clients' confidential information secret!
Right now we don't have any prospective clients that have projects that would call specifically for C++/native stuff. We have some clients that may have problems that need to be solved with that kind of work in the medium-term future.
Ideally we're looking for engineers that have a pretty-broad skill-set, that are happy to pick up new frameworks, languages, and code-bases as necessary.
Damn, thanks for pointing me in that direction. It's exactly what I've been looking for.
Technically, I implemented some of that stuff myself because I needed REST client that would work with PCLs and be a bit 'nicer' to use than just juggling strings/routes everywhere, so using annotations and wrapping Microsoft's HttpClient was obvious and relatively easy way out.
Anyway, I'll probably just phase out my own solution and start using the library.
[EDIT]
After checking it out, RefitStubs.cs file seems a little bit clunky, but the library as a whole looks solid enough. I'll look further into it.
RefitStubs is necessary because on certain platforms (iOS, WinRT), you cannot JIT and therefore can't use something like Castle Core to generate a class
On the other hand, I wonder if it wouldn't be easier to ship a T4 template? I know for sure that would integrate with VS (both the IDE and build process) without any issues, not sure about Xamarin Studio...
Benchmark: C# (Mono) - 1052.041381 ms, Java - 597.9874 ms
My machine: C# (Windows) - ~475 ms, Java - ~552 ms
Even considering that Mono is using maximum precision available (so instead of floats it's using doubles), when I swapped all floats to doubles it still ran in ~525 ms on my box.
So while Mono might be 'getting there', sometimes it's still lagging behind. It's just something to keep in mind :)
Even then, for query building I found EF (or any LINQ provider for SQL) to be easier solution than string concatenation. Well, at least for relatively simple queries with pagination and stuff. For filters, Dynamic.Linq would be helpful here.
On the other side, if you need to work extensively with stored procedures or you have complicated or custom SQL to run, Dapper (or Insight.Database - https://github.com/jonwagner/Insight.Database, a library which I found really nice to use) will be your best friend.
It's true. What I really would like is a micro-orm like Dapper with support for using LINQ to dynamically build queries. But I suppose this is essentially EF with AsNoTracking, which I have yet to play around with and test performance wise.
AsNoTracking makes the materialization indeed faster, but EF always has a cost associated with it, both for initial use (set up of the context etc, which is noticeable) as well as every other query after that (expression tree parsing etc, not as noticeable especially for recurring queries).
I hope it's one of the pain points they will address and solve during their rewrite to EF7 at one point.
That being said, my opinion is that unless you have really strict performance and/or latency requirements, EF should be good enough. At least for simpler queries and in 'longer-running' applications :)
My testing showed that AsNoTracking is faster than dapper. But indeed the tests were purely focused on materialization and not query parsing: linq query parsing takes a lot of time, so with lots of predicates etc. you'll see much slower performance with EF compared to other ORMs with query systems other than Linq (except NHibernate, that's slow regardless)
Just something to keep in mind when using it as a substitute for subquery, readability vs performance and all that :)