As a pianist the key here would be musical versatility, there is a lot of work but it is spread across musical domains.
The musical skills might include reading literacy, proficiency in improvisational idioms and the ability to teach these things.
The more difficult realm might be establishing a working band of professionals, per individual the professional attitude would be worth more than sheer musical skill. Professionaly minded people working together can build skills that will eventually surpass what an individual can bring alone.
Networking is important, there's lots of ways to engage with your immediate community and it has always helped me to reach across as many professional aisles as I can. How many high functioning professional musicians do you think the average person knows? You should be one of them for the people close to you.
EDIT: I'd like to add venue versatility. Most discussion seems to be around entertainment venues but what about educational, accompaniment, theathrical, ceremonial, religious (I do not personally partake in this).
As something like a solo pianist, I would say you might be able to scratch out a living using all the various outlets you described -- teaching being primary among them as far as ways to generate income.
Haven't tried Reflux but I would recommend trying Redux before it. It is heavily inspired by Elm and has been very pleasant to work with. Reflux also bypasses the 'unidirectional data flow' part of Flux, which gives you added convenience for some things at the cost of more complexity.
Well this is pretty exciting. This opens up the door for PS4 games to be written in any language that uses LLVM as a backend, right? So in the future, PS4 games could be written in D, Rust, Ada, ActionScript...
Especially with the indie focus Sony has had, this could make it much much easier for people used to creating games with ActionScript to get their game on a console.
Is there something I'm missing? This seems too good.
Retail consoles only run code signed by Sony. When you become a licensed developer you get special consoles called devkits that can (among other things) run unsigned code.
Not only that but devkits also come with the SDKs and tools and access to the developer network. Plus they cost thousands of dollars. They also usually have double the specs of the retail console to run debug code and tools. Even USB connectivity and plugins for VS to debug code running on the devkit remotely.
Also on our Vita devkits there is no battery to make space for the extra ram.
Even with the open sourced compiler you're still missing most of the toolchain.
>> Not sure I follow - what is stopping non-licensed developers from developing and testing games on their own PS4s now that this has happened?
I don't want to come across as being mean or anything but...
How charmingly naive!!
Sony (and the other console makers, to be fair) go to absolutely incredible lengths to make sure that people absolutely do not get to run their own code on these machines. And then they sue anyone that finds a way to do so.
>Sony (and the other console makers, to be fair) go to absolutely incredible lengths to make sure that people absolutely do not get to run their own code on these machines. And then they sue anyone that finds a way to do so.
Also, to be fair, PS4 is the first Sony's home console that does not run user's code. All the previous Playstations had such an ability in one way or another:
I don't see a reason to buy a console unless it has a large number of exclusive titles that are worth playing. (Which in itself is anti-consumer. I want the games not the hardware)
PC gaming is currently the best choice. All the freedom combined with better hardware. The only disadvantage is the high cost of entry but you can easily save money by buying games during the big sales on steam.
Handhelds are a different story though. The games are often a lot better than mobile games.
Well....I have both a beefy gaming pc and a next-gen console. Yeah, my PC is more powerful and can run anything you throw at it. But most of the time I simply enjoy just sitting on the sofa with a controller in hand, one click the console is on(and it turns my TV and amp on as well), another click and the game is launching. The system is quiet and uses less energy - my £1200 gaming machine sure has an overclocked CPU and a custom cooling system,but it doesn't change the fact that it has a total of 7 fans and uses 400W while running games - I had it in my living room for a while but didn't enjoy the whiz of air. In fact, I bought Dragon Age Inquisition on PC to enjoy better graphics, but after the latest Nvidia Driver broke the game(huge FPS spikes, artifacts everywhere) I just bought a console version. Pop the disc in, go. No drivers, no config, it just works. Sure the graphics are slightly worse,but not enough for me to care. And the price of games was literally never an issue for me - just the lack of time to actually play them.
The retail versions of modern consoles enforce cryptographic signatures on everything, so nothing will run on them without going though MS/Sony/Nintendo first.
Officially licenced developers have special devkit systems with more lax security.
Sometimes fancy extra features too- I believe I've heard of (and seen photos of) devkit systems that interface to a PC for uploading code and/or debugging.
I have a PS4 devkit on my desk. Basically you develop in Visual Studio like you would normally, press run and the application gets deployed to the PS4 over lan - debugger also attaches remotely. So from the programmers point of view you don't even care that your code is running over the network. In fact, I have worked with Wii/WiiU/PS3/PS4/X360/XOne devkits and you can always deploy remotely through lan - with the only exception being the Wii, which used 3 USB cables at once for deployment and debugging.
That's pretty sweet! No wonder with the Wii, I understand it was the last holdout of the older group of consoles, what with the double-clocked GameCube CPU and all.
Don't think that Wii U is much better....it has a lan port, but literally every tool is command line based and their debugger looks like notepad from Windows 95 with few extra buttons tacked on. There is a plugin for Visual Studio integration, but it's super slow, when you hit a breakpoint in code it takes over a minute to trigger in the IDE, so everyone uses their horrible outdated debugger instead. Nintendo hardware is very weird to develop for.
I don't seem to have access to the VS plugin, but when I place a breakpoint in the Green Hills IDE it is indeed about 30 seconds for it to catch up. It works, but I do find it frustrating.
Glad to see another language that has chosen to avoid NullPointerExceptions. Some of you might take issue with the way it is implemented (special syntax vs general type), but IMO it is still much better than having NPEs.
> Digressing, were there any discussions about using var like in Swift (instead of let mut)? What is the rationale for not making that more minimalistic?
I was interested in the answer to this too. I found these which helped me understand:
Here is a practical everyday example where languages that can represent emptiness in the type system come in handy.
He ends up using pointers and mentions: "Using pointers also means that clients of the library will need to perform their own nil checks where appropriate to prevent panics."
> Using pointers also means that clients of the library will need to perform their own nil checks where appropriate to prevent panics.
In practice, as your Rust comment alludes, I find working with nil properties in Go types (used to shuffle between the DB and JSON) to be quite painful. I end up keeping track of a lot more state than I really want to, and errors can be introduced subtly.
In Go, you can usually use a type's zero value without doing anything special. But if that type contains any nil properties, you can't presume this anymore. If I have:
type Thing struct {
ID int
Bad *string
}
I then have to do nil checks in every method that might handle Thing, or I have to make it accessible only via functions which perform those checks for me in advance. Either way, much less convenient.
> How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it?
I don't quite get how this header makes you invulnerable to XSS, would someone mind explaining?
It seems like it only prevents XSS attacks from loading remote javascript files. What's to stop the attacker from just injecting the entire script inline? If you can get a small piece of javascript to execute you should be able to get a larger piece to execute just fine.
I can see how it makes XSS more inconvenient, but I don't understand how it makes you largely invulnerable to it.
Inline Javascript is outright banned by default. Read the HTML5Rocks article they linked, it is much more comprehensive and answers most of the questions like that that I had.
Ahh, now that makes sense, thanks! The HTML5Rocks article cleared up my concerns.
For anyone reading this later, it was the section starting with this paragraph:
Inline Code Considered Harmful
It should be clear that CSP is based on whitelisting origins, as that’s an unambiguous way of instructing the browser to treat specific sets of resources as acceptable and to reject the rest. Origin-based whitelisting doesn’t, however, solve the biggest threat posed by XSS attacks: inline script injection. If an attacker can inject a script tag that directly contains some malicious payload (<script>sendMyDataToEvilDotCom();</script>), the browser has no mechanism by which to distinguish it from a legitimate inline script tag. CSP solves this problem by banning inline script entirely: it’s the only way to be sure.
