1. People that have an application and want to insta-create a REST API for it
2. A backend-as-a-service for people that don't want to do any backend coding (mobile apps, web sites)
250 karma · joined August 3, 2013
2. A backend-as-a-service for people that don't want to do any backend coding (mobile apps, web sites)
And then creating a bar with version 1 to 7 would use the views in each schema to insert it, but it would actually be inserted into the database in schema 1?
You create a new schema called "2", change the foo table and release it. As a side effect you also have two versions of bar that are identical. If a client creates a bar+v1 then it goes into the first schema, and if a client creates a bar+v2 then it goes into the second schema.
So you think "fine, I just won't publicise that, clients will only know bar+v1". You continue to make a few more changes to foo, bumping up the version number each time, and then you want to make a change to bar, so you do that and you then have a bar+v1 and a bar+v8.
-- "There's no reason you can't change your data model with this. Why do you think you can't?"
You can with this through the versioning and different schemas. I meant more generally that exposing your DB and then making changes would break consumers of your API, forcing you to freeze your data model instead. Using schemas is a novel solution, horribly hacky but I guess it works.
But generally, DO NOT tie your external APIs to your data model unless you can can commit to never changing them. (hint: you can't).
--- Edit: The versioning is whole API versioning instead of resource versioning and works by using a different db schema for each version. This is a terrible idea and I wouldn't recommend using this at all
The country is huge and could easily cover more than one timezone, I'd hazard a guess at political reasons based on that, but don't take me as an authority because I'm not
Language is fluid and always changing, if you start to spell words using the IPA then you need variations for every different accent and you need to update the spelling as accents change over time.
Words have almost always been written down as they sound, but then the way that we say them changes. Some changes in written language happen, an obvious contemporary example being the differences between UK English and US English. But writing in IPA would mean that we need to update our written texts as our language change or it would mean that every person has to speak it the same way and in every location forever, and that you need to police it so people don't speak incorrectly.
"Argentina determines whether to observe daylight saving time on a year-by-year basis, and individual provinces may opt out of the federal decision. At present, Argentina does not observe daylight saving time."
As someone who works with clients in different parts of the world I really do long for a single time zone that we can all share. In local life will 12 noon will always be the ~same time, but for business I don't care.
Usually I try to use UTC, but it's not always successful, and just trying to pin down a suitable time to speak to someone across timezones can be difficult.
---
However, "replacing all writing with the international phonetic alphabet" is a terrible idea
Many people don't even know the context or the original quote. And many times I've seen discussions about improving a piece of code shot down by a single incantation of this Knuth. It's sad.
Remote preferable
I'm a backend JVM programmer, my language of choice is Clojure. I also have extensive experience with Java and Scala, and some with Groovy. But please don't contact me about Scala.
More info: https://encrypted.google.com/search?hl=en&q=dan%20midwood
Contact: seekingfreelancer2747e8c@danmidwood.com
However, if this is the case, then the criticism here against React shouldn't be that they're not reactive, but that they've used "reactive" wrong in their documentation.
Like other commentors, I also don't like the message in the slides and do not think that criticizing a competitor is a good form of marketing. But, I do think we should remember that it's hard to get the full context from slides and to not judge too quickly.
Right now it is an extremely concrete example, and really easy to say that the originator of the bot is at blame and should be prosecuted for buying illegal items.
But, how advanced does a bot have to be before it itself is at blame? What if they'd programmed it to reach out and purchase from any vendor it could find? What if it wasn't programmed to do anything but made random acts, took feedback and then learned from it?
* Directed learning by reading.
* Undirected learning by videos.
That is, if I know what I want to learn then I can usually go straight to it in books. If I just have a general fuzzy idea then videos tend to offer a higher level view that can help me to clarify my understanding.
I think videos are a poor medium for highly detailed learning. If you're looking for specific information then a book is much more easier to skim than a video is, it's not a good prospect to spend time watching a video to discovered that only 1% of the content was novel and relevant.
I use IAWriter for it, but you can literally use anything.
I hit this problem once. I was working on integrating some software with a public API when Self Control blocked access to the same API. Fortunately I'd only set the timer for a short while so I just had to wait it out.
† https://github.com/SelfControlApp/selfcontrol/wiki/FAQ#q-oth...
Point 3, I think they already have covered. I think it's pretty safe to say that the BBC is a well known and established brand, and also a producer of high quality content.
The best way to look at it now is that they're stuck in a local maxima, they could definitely gain by broadcasting online to the world but it might take some time and will most definitely hit them financially in the short run.
There's also a political aspect wrt the BBC too. They are, as per their mandate, completely politically neutral†. But generally the left side of politics supports continuing the license fee we pay where the right side doesn't. If they should suddenly take a significant drop in revenue and it subsequently does affect what they produce then it also puts them at risk. And the last thing us Brits want to see is our BBC channels filling up with adverts.
Now is an interesting time. For a long time they were a plain old tv broadcaster. Now they're on the internet and broadcasting things there there are people questioning whether they should even be doing that. Eventually I think things will stabilize into some condition, I don't know what but I don't think we are there yet.
† of course, with politics, there are many debates about this
With the internet they have limited choices:
* Keep things off the internet and disappoint everyone
* Put things on the global internet and lose export value
* Put things on the internet but geolocate to the UK and retain export value
Clearly for them, the quality of their shows, and for the British public, the last option is the best.
It's a strange system because the BBC is considered public broadcasting but is still funded (i.e. paid) by us citizens. You have to take the UK only as a subscription that we have implicitly paid. Of course, it would be great if they offered an outsider subscription, but there are undoubtedly internal political reasons why they haven't.
Many people are working remote by default* and already have to fight certain perceptions that they are just sitting in their pants, watching tv, and eating chips all day, and it certainly doesn't help when others liken working remotely to being a holiday.
It's definitely a good thing that more companies are opening up to remote work and trusting their people to get things done without being watched over, let's not perpetuate this idea of it just being a bunch of slackers that do it.
* including me, obviously, and hence this response.
When I see code like this I will assume that it's going to check every condition:
if !complete {
// do something
}
if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 {
// do something
}
if r.Created {
// do something
}
The recommended way means that I can't trust my assumption and that I'll have to read the entire function and examine the `//do something`s instead
The biggest problem I have had most so far is when reading other code, finding the meaning amongst all of the error nil checks and the sprawling if conditions that they bring.
Another thing that makes it difficult is the preference for scattering returns everywhere and avoiding `else if`s, I read code structurally so code like this from slide 29 (http://talks.golang.org/2014/readability.slide#29) is really difficult to parse.
func finishStatus(r Result, complete bool) int {
if !complete {
return http.StatusAccepted
}
if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 {
return stat.Code
}
if r.Created {
return http.StatusCreated
}
return http.StatusOK
}We most certainly are, there's very little may be about it.
It's nice that we can see Javascript (albeit, often minimized) but we should never assume that visibility === free.
My own problem was being too attracted to novelty, every little bit of information that arrived in front of me was the most important piece of information in the world. But, before I could act on it, the next piece would arrive. This manifested in me having a long lists of books and articles to read, things I wanted to do, things I wanted to learn, and, eventually, dissatisfaction because I couldn't keep up with it all.
I "solved" my own problem by just routing every distraction as it arrived into a look-at-later list. Then when later arrived I'd scan through, decide what was actually worth following up on and just delete the rest. If you do this then you will realise how unimportant most of those distractions were.
Going onwards the key is not to have 10 books and 800 articles and 100 more articles, I'd suggest purging them. Focus on one book, ignore the rest. After you finish that first book then pick one of the rest. If some of the books were just bought on a whim and you don't have the enthusiasm to read then just delete them, it's not a problem, no one will judge you. Delete all of the articles, if they're important enough then you'll see them again.
Afterwards, don't buy any more books until you've finished the ones you have. Notice the difference between not wanting to read a book that you have and wanting to read the one you're thinking about buying. Is it really important? Do you need it now?
With the articles, continue to use Instapaper, it's a great way to avoid the immediate distraction. But only keep a limited amount of things in there. Notice how quickly you add new articles and how quickly you read them. If you're adding faster than you can read then delete the surplus. And if you notice the list becoming unwieldly then delete them all and start again, you won't miss anything, nothing is that important.
The same idea applies to many things, remove the impatience of "now!" and it's easy to view and prioritize them. You'll never be able to do everything, so just do the things that you want most and purge the rest. They're not important, it doesn't matter.
There seems to be a rejection of design in OSS (less so these days, I admit). I really like the idea of judging software solely on how it stands alone, but people don't do that, and to many this will just come across as amateur.
Remote: Yes
Willing to relocate: No, but I can visit
Technologies: Clojure, Scala (+ a history of others)
Résumé: http://resume.danmidwood.com
Email: anything @danmidwood.com
Website: http://danmidwood.com (contains blog posts + links to Github, Twitter, etc)
I think the only criteria on what I'm looking for is that it's technically interesting and justifiably complex, something that I can get passionate about and that will make me have to really push myself, think and learn.
Tech: Clojure, Scala, Javascript, Java
My usual focus is in back end functional programming, architecting systems and RESTful API design.
You can find out more about me and what I can do for you from my website, where you'll also find links to my résumé, github, twitter, etc and a way to contact me.
When I first started with Paredit I struggled to absorb the functions and key bindings from the manual and cheat sheets well enough so that I could use them while writing code. I know that seeing them in action would have helped me a lot, so I made this and put it out there, I really hope that it can help other people to start using more of Paredit.