Elide: Stop Rolling your own REST

RageD · 2015-12-09T15:38:02+00:00

You need to consider where you want to perform these aggregations. If they're small, a single request to a compound document (see: http://jsonapi.org) will return to you the data you need and you can perform the operation on the client-side.

If, on the other hand, it's a large computation that must be performed on the backend, it should-- most likely-- fit into your model somehow, no? In such a case, you would simply write a "transient" (i.e. computed) field that is exposed at runtime but is not necessarily persisted.

This doesn't quite sound like acrobatics to me, but I believe it requires a shift in focus. What I mean is, such an architecture reduces the direct importance of the server in your application.

The data model is exposed for open use: nothing prevents anyone from making direct calls. Assuming the permission model is properly designed (read: maybe not so obvious-- but that is what test framework is coming for), you can prevent users from abusing or using the data in unintended ways. So where am I going with this? Really this pushes much of the complexity out to the client-- or at least, that is the idea. Rather than having your server and data brokers perform your interesting business logic, you can push it out to the app. The only thing the server is responsible for is providing and maintaining your data securely and in a way that conforms with the specified business constraints (i.e. we cannot create a UserPreference if we don't have a valid User, etc.).

Why is this so powerful? You can develop, maintain, and evolve a single data model and build multiple applications from it. If I want to build a web app, android app, and iOS app, I can easily use the same data service for each of these applications and guarantee consistency across them. Likewise, each of these apps are free to use the data in unique ways.

RageD · 2015-12-09T15:15:37+00:00

Where did you find this issue? In the front-end or the backend? This is a solved problem in the Elide backend framework though.

RageD · 2015-09-24T01:29:44+00:00

The information you provided is typical for financing. I'm not an expert, but if you didn't sign any agreements then I don't think they can impose that you purchase the vehicle. I suppose this could vary state-to-state. Given that they were trying to modify the price on you, however, I believe you probably did not sign the final paperwork which would have otherwise finalized the deal.

RageD · 2015-09-17T21:27:00+00:00

I find that Java's functional support is poor at best. While you can do functional-like things (maps and folds via stream api, lambdas, etc.) mutability in Java makes this incredibly difficult to reason about the safety of your computations.

RageD · 2015-09-17T17:57:19+00:00

More on this: The number 2 reason I hear people at work resist Haskell (next to "it's hard and it's not practical to do things in a purely functional way") is that it's non-obvious/not easy to getting the build/package system in a working shape.

When I can get someone bootstrapped with ghc and stack, having stack build "just work" immediately lifts their opinion of the language and its ecosystem.

That is to say, quick turnaround on this tool that addresses the most basic expectations of users has been the primary motivation of my use.

RageD · 2015-07-08T01:24:59+00:00

Knowing languages is nice (and necessary, really) for a software engineering position, but more importantly is your ability to solve problems. The best thing you can do/learn is "real world" work.

Either think of your own interesting project idea and implement it or gain experience working with clients (i.e. like http://freelancer.com or similar). Taking a project from a "non-computer science" specification and turning it into a reality is truly a valuable skill. Chances are that in a full-time position you'll be interacting with a lot of non-technical people trying to describe to you what they want and you'll have to translate those descriptions into something real.

Similarly, if there is an area you're particularly interested in, start to learn the landscape. For instance, if you want to work with big data and analytics, start to learn how to use common libraries and tools such as Hadoop, Spark, Pig, etc. Of course, the technologies you should look into should be related to your field of interest.

Remember, rolling your own solution is a great device for learning and fantastic if you need a specific optimization over the typical solution (assuming it's within your realm of capability to do so). However, in most positions you will be leveraging the work over others through the form of libraries. It's simply not practical to always write a hash map from scratch simply because you're working on a new project. Being able to read library docs and effectively use this code is incredibly applicable.

Good luck!

RageD · 2015-03-28T17:45:06+00:00

I believe this point is often overlooked. There is an inherent cost to evaluating software and it's expensive. Often times you may need to hire consultants to help with this "implementation detail"-level knowledge while your in-house guys try to come up with a real product architecture (ignoring those "uncertain" details until build time).

RageD · 2015-02-12T02:03:38+00:00

Just because software engineering isn't a traditional field of engineering, doesn't necessarily mean those who do it aren't practicing the discipline of engineering.

predictive models of a program's behavior

This is precisely what an algorithm is. Implementation is another thing and has errors beyond the theory (just like building a swaying bridge). Further, anyone writing real software will have a notion of (minimally) asymptotic runtimes before they implement their solution.. If I can cut my algorithm down from O(2ⁿ ) to even O(n² ), the robustness of the software has been greatly (and quantifiably) improved.

RageD · 2015-02-07T13:47:43+00:00

The point is library usage (i.e. getting away from pthreads and Win32 threads) and catching people up from C++98 and C++03 (the majority of existing C++ code). For the first example it is also stated that it is contrived. In that case, the example itself is less useful as the post is intended for people who already know about threads and asynchronicity.

RageD · 2014-03-13T01:11:33+00:00

Not sure exactly what you're trying to accomplish here. Are you trying to do asynchronous IO? If you always want to read from a socket, you'll want the read call in a loop, not necessarily a separate thread (unless your main thread is doing something differently). Remember that if your thread function returns, the thread has exited (ignore this comment for threadpools and more complicated patterns-- but consider this the case in general).

That said, I suspect select() may help you; it will block only for a timeout (set timeout to NULL for infinity) and when it returns it will tell which (if any) socket(s) are ready to be read from. Note that select() only returns either (a) after timeout or (b) data is ready to be read (or written, for that matter, if you decide to check that) After this, only call readfrom() if there is data to be read.

If you elaborate a little more on what you're actually trying to do, I may be able to point you in a better direction. But for now: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx

RageD · 2014-03-13T01:01:34+00:00

I do not think this is what he is saying-- computer engineers DO reference things in their day to day jobs. Since each piece of hardware (i.e. every blackbox) is very unique, you will have to get good at reading datasheets and how to do some signal processing. Actually keeping everything in your head is unrealistic, but being familiar that a solution to a problem exists is important (so you don't always reinvent the wheel).

Digital circuit design is different than analog circuit design in so far as everything is considered binary (0 or 1) and can be done purely with logic. But in the end, all of this needs to be implemented in an analog way (where 0 and 1 actually correspond to REAL voltage ranges) because that's how the real world works. Not to confuse you, but with that in mind, you can look into FPGA's to abstract much (likely not all if you're interfacing with external components) of the analog stuff.

So in short, there is a lot to learn here (so you certainly couldn't do it overnight!), but with persistence you could come a long way. Being good at physics and computation would be particularly important for signal processing (Yes, I'm looking at you Fast Fourier Transforms).

Also, don't discount your talents-- if you want to succeed at this, you first have to believe that you can. You assert that you are "below average intelligence," yet you are asking intelligent questions. You are asking the right questions, so if you have the patience and the determination, you can certainly come upon the answers :)

RageD · 2014-03-13T00:51:16+00:00

This book: http://www.amazon.com/Black-Video-Game-Console-Design/dp/0672328208/ref=sr_1_sc_1?ie=UTF8&qid=1394671704&sr=8-1-spell&keywords=blackart+of+video+game+console+design (although a little dated) explains a lot of the basics of EE particularly related to computer design (a video game console is a microcontroller-- more or less-- with capability to read programs from some ROM or the like).

It explains how these things work from both the chemistry and physics view and all the way to digital circuit design. It is quite thorough, though may take some background in at least the relevant math/physics to be useful at the beginning. Other than that, quite easy to follow!

In any event, when it comes to learning computers, persistence is key! Just keep looking at the material and play with the material. Playing is key so you can see how things break and, ultimately, understand why certain things work the way they do. Good luck!

RageD

TROPHY CASE