This version no longer bundles the MTG JSON data but instead pulls it directly from mtgjson.com. Every two weeks or so the extension will check mtgjson.com for an update and if one is available, download the latest version.
Atheists have no problem professing (based on the apparent evidence of the cosmos) that human beings are profoundly, mind-bogglingly insignificant; yet they take it as a personal offense when Christians assert that God is not beholden to us. There is no rationality to this response but only wounded pride.
For myself, and probably a few others here, we take issue with God's punishment as being some form of justice. We as humans have evolved a sense of justice and condemning someone to eternal suffering for one act in a litany of seemingly insignificant acts offends that sense of justice. Furthermore, it becomes insulting when someone dismisses our umbrage with reasoning that God works on a different level. It's that justification that has been used throughout history to allow some people to rationalize brutality against others. Perpetuating that attitude, and not any sense of pride, is what gets me riled up.
My main reason for still believing in God in some form is this. At some point, someone or something had to have started everything. The Big Bang had to have happened somehow. And even if there were universes before the Big Bang, they had to start somehow. The only thing that I can think of that would be capable of this would be God. So I believe in God existing.
So an unmoved mover. To prevent this from being turtles all the way down, why does the universe in this case require God? In other words, why ascribe the universe to God instead of just letting the universe be the "prime mover"?
Pricing information appears garbled. As best as I can tell you're dropping the decimal point. A Worldwake Jace, the Mind Sculptor is low listed at $85.01 at TCPlayer but your response is 8501.
Just because you'll have access to an IDE doesn't mean an interview shouldn't ask basic questions. You'd be surprised how many people have all of the asked for requirements yet aren't actually qualified for the job (not accusing the OP of anything, just saying).
That's to be expected, of course. But putting a seasoned developer into a situation that just isn't going to happen not only wastes his time, but yours (the interviewer) as well. Interviews need to be about seeing how an applicant thinks and evaluating how well he can mesh with the team. Any sort of evaluation on basic syntax is something that should come beforehand either through checking the applicant's references or, better yet, their Github (or equivalent). Honestly I don't even consider a person unless they give me some sort of link where I can evaluate their work.
I could maybe see testing a junior developer to make sure he actually has some knowledge of a language, but even then when I'm hiring a junior developer I'm looking for potential.
There's also something to be said about how well someone codes, e.g. industry standard syntax. It can actually cost a lot of money (time) for a resource to have to take the time to decipher bad code.
Depending on the complexity of the task and the time allotted for the test, what gets churned out might not be of the best quality no matter who writes it. I'm a huge proponent of using frameworks instead of writing new code, of using patterns when applicable, and of test driven development. Being plunked down in an unfamiliar development environment and told to code without tools meant for the job is going to result in rough code no matter who you put there.
Really I'm all for kick-the-tires challenges; I use them myself after I have interviewed someone I believe is a good fit for the position. However, I test them in a way that shows me how they work in realistic conditions. I want to see their development process, how they interpret requirements, how they cope with an unfamiliar code base. I don't want to see if they know how to make javac not error out because I'm not using javac to compile my code (and everybody else in enterprise Java development shouldn't be either).
I am supposed to have an interview with a large tech company that doesn't mess around. Apparently, I'll have 45 minutes to write code without the use of a compiler/IDE. I don't want to go in trying to recall details I learned 10 years ago.
This sounds asinine. There is literally no situation where you won't have an IDE. Testing your knowledge on Java syntax is hardly going to evaluate your skills as a developer. A good company will want to know your experience with industry standard practices and common libraries. Seeing if you know the syntax of a language should be evident during a kick-the-tires tryout by letting you code like you should.
In my opinion you're probably not headed for somewhere you'd want to work. Any company that tests its applicants in scenarios that just aren't going to happen are likely being staffed by people who haven't adapted to changes in the industry. Anybody who wants to "evaluate" your programming skills outside of an IDE is probably somebody who thinks real programmers do it in vi (or emacs). Teams led by those kind of people are teams you want to stay away from if you ever want to advance your career.
I've been a programmer for a decade now and I've only ever been asked once to forgo an IDE during an interview. The guy who asked had been programming in C for 30+ years and didn't trust anybody else's code, including GNU. That's a huge warning sign to stay far, far away.
If the interview has already happened then I hope it went well. If not, call them back and tell them you feel that any sort of test under unrealistic conditions is not going to give them any real insight into your skills. If they push back, go look for a job somewhere else. It sucks to turn down an interview (or even a position) when you really need it, but having to work for any company that treats you like a junior developer fresh out of Comp Sci 201 is worse.
Open Chrome and click on the address bar. Type in the following and hit enter: chrome://gpu
You'll see a page with some technical output. At the top under the heading Graphics Feature Status will be some bullets. Next to CSS 3D should hopefully be some green text. If there isn't any green text then your computer's graphics capabilities aren't going to work with Scry (for now).
It's unlikely to be that your computer is too old, but rather that something about your graphics card/driver is buggy. Chrome will disable hardware acceleration when it detects some graphics cards because of really bad bugs in either the hardware or driver.
You can try this workaround and things might start working for you. However, Chrome blacklists things for a reason so disabling that could cause other issues. YMMV.
In other news, I've updated Scry to 3.6. This update should get pushed out soon.
Highlights:
Updated Oracle database to MTG JSON 1.6.
Plane, phenomenon, and scheme support. Large card goodness.
That's definitely not supposed to happen. I have a sneaking suspicion Chrome's not using your computer's GPU for CSS transforms.
Can you post what you see at chrome://gpu? If Chrome's not using hardware acceleration for 3D CSS I'm pretty sure you won't see the backside of a card. I'll have to really mull over how to fix that one.
I would love the "buttons" (grey boxes) to be outside the card frame, rather than inside. Currently, when viewing the Oracle text, the boxes get in the way.
Just uploaded version 3.5.1 that addresses this. The controls are now outside the frame. The effect is actually quite fun to play with. Way better than before.
I also missed the ability to click on the Sun/Moon/Picture to Transform/Flip a DFC. Could this be reverted?
Probably not. The control menu has started to give a unified look to the popup. In addition, discoverability is higher now that controls are presented all together as opposed to multiple hotspots around the image.
Backwards compatibility of the last gen was a tricky thing to implement. Early PS3 systems actually included the necessary bits of a PS2 to obtain backwards compatibility. PS1 games are emulated and have been so since the PS2 days.
Emulation only gets you so far, though. Perfect emulation takes a massive amount of hardware so most emulation isn't exactly right. For example, original XBox games on the 360 are emulated, but via downloadable bits that handle the tricky emulation for that single title. Even then, emulation specific bugs crop up. Emulating 360 or PS3 games is pie in the sky; last gen consoles are still far too powerful to emulate.
Another option that wasn't really possible before is cloud streaming. Current gen consoles could use a service similar to OnLive to "emulate" last gen games. Performance would be highly dependent on network bandwidth.
The biggest hurdle, though, is companies have discovered that rereleasing back catalog games is profitable. Texture updates and some code shims to the new APIs are all that's really necessary to put an older game back out on a digital marketplace. As long as Sony and Microsoft can do this to their own titles and continue to receive pressure from other devs backwards compatibility is going to quickly become a thing of the past.
Here's the problem: people can saying "change the tone and you will never have a problem", that's your guys guarantee, but it says in the forum rules when posting about rulings that "1 post is sufficient". Logically, there's no way a single post from a random person who I've never even met is sufficient for me to be sure of anything either way, so get rid of that rule and tone won't be an issue. I've asked for second opinions more than once and I intend to do it again, I don't want to get a warning every single time I do.
I'm going to use an analogy. Be warned; like most analogies it isn't going to be 100% accurate but you should get the gist of it.
If you're sick and you go to the doctor do you question his diagnosis every time? If he says, "You've got the flu," do you respond, "Can you get someone else to give me their diagnosis?" Probably not.
The rulings forum here is very much like a doctor's office that's staffed by doctors. More often than not your question will be answered by a resident instead of a full MD, but it's not like that resident is a guy coming off his first FNM win after playing for a couple weeks. The answer you're given is highly likely to be correct, and, as already stated here a few times, will be quickly corrected by others if needed.
Remember, the rulings forum is a voluntary effort and you are not entitled to answers, correct or otherwise. Insisting on having a judge or RA answer or confirm answers for your questions is crossing a line and is a good way to get yourself on a lot of people's ignore lists. Instead, trust the system; you're not going to get accidentally diagnosed with the plague here.
So you might notice a bug with DFCs. Flip to the back side and you can't drop the info panel. In truth, this bug manifested before the info button was added; you just couldn't switch to the printings or prices tabs.
Turns out it's a Chrome bug. So if you'd like to see it fix, I encourage you to star that issue. DO NOT post anything like "+1" or "Me too." Just star the issue and it will move up the priority chain.
In the mean time, I'll look at alternative locations for the info button.
Might've been my mind playing tricks on me, but I thought they looked pretty sharp when on version 3.2. Was there a change in the rotational code there?
3.3 had a big change to the layout and how certain transforms were handled. Turns out you were correct and 3.2 had sharp images on split cards. I've fixed this in the upcoming version.
CSS3 transforms are still in flux and, while widely supported, some parts aren't quite up to snuff in some browsers. Parts of Chrome's CSS transform handling really screws with images. So what happened?
To rotate the image we apply a CSS style with -webkit-transform: rotate(90deg). This of course also changes where the image is positioned in relation to its parent container. In 3.2, to get the image positioned back to where it was I applied a -webkit-transform-origin that shifted the image to the right place. Side effect was that the image was blurred slightly.
Now I'm not sure why I didn't try it before, but to fix the blurry images, I simply move the image container so it's again positioned on top of its parent container like it should be. Really simple fix that I should have tried before messing with transform-origin. C'est la vie.
Nothing we can do about that then. Not even possible to make it another image? As in, a solid black image that's stored locally? WebKit seems to do those transformations fine with the card images. Worth a shot?
Even then it wouldn't work.
The way the layout is now is thus:
There's an overall container that holds everything.
Inside that container is a image container that establishes the border color, size, and corner roundedness.
Inside that container are the two images element (really a div with a background-image). For most cards one of those image elements is nothing and the other is the card image. For DFCs each side takes an image element.
The two image elements are positioned on top of each other and back to back, just like a physical DFC is like.
Transforming the card rotates the image container around the central axis, bringing the image in the back forward and moving the image in the front to the back.
The flicker happens if the top container that holds everything has a background. When the image container rotates the browser is trying to draw the top containers background between each frame.
However, I figured out a way to keep track of when an element is being animated. So in the upcoming version the top container will have a black background and the background will disappear when the animation begins so there is no flicker. I'm not going to try and match the background color to the border because that would make things more complex than I'd like.
So in the next update, which I just uploaded, has a couple new things. First off, cards are draggable again. Dragged cards won't hide unless you click the close button (which you won't miss). Also, the info toggle is now a button that you can't miss either. Easier to click too.
Split card images seem a lot more blurred than they were.
A side effect of webkit CSS transforms. Back when images were pulled from Gatherer I could specify a rotation and that was done on the server. Now, images all come in one orientation and Scry has to rotate the image client side with a CSS transform. Problem is, that transform blurs the image slightly. Annoying, but not sure what I can do about it.
I did find something in the chromium issues about a similar issue with text and rotation and a workaround was posted. I'll have to give it a try.
When you initially load a card, a black frame over a transparent box is seen. Could that go back to a black/white box (depending on the border) again?
It's also noticeable when loading a lower resolution card (it doesn't quite fill up the box). Problem is, making the background a solid color causes the flip and transform animations to flicker considerably. Chalk it up to another webkit issue.
Lastly, really minor. The Sun/Moon icon for Garruk Relentless is out of sync with the glowy circle. Is it worth making an exception for that? It could become relevant if more DF Planeswalkers get released.
That's bugged me too. I might be able to do something about it.
Undead Warchief
Death Baron
Lord of the Undead
Cemetery Reaper
Diregraf Captain
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
This version no longer bundles the MTG JSON data but instead pulls it directly from mtgjson.com. Every two weeks or so the extension will check mtgjson.com for an update and if one is available, download the latest version.
Let me know if there are any kinks to this.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
For myself, and probably a few others here, we take issue with God's punishment as being some form of justice. We as humans have evolved a sense of justice and condemning someone to eternal suffering for one act in a litany of seemingly insignificant acts offends that sense of justice. Furthermore, it becomes insulting when someone dismisses our umbrage with reasoning that God works on a different level. It's that justification that has been used throughout history to allow some people to rationalize brutality against others. Perpetuating that attitude, and not any sense of pride, is what gets me riled up.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
So an unmoved mover. To prevent this from being turtles all the way down, why does the universe in this case require God? In other words, why ascribe the universe to God instead of just letting the universe be the "prime mover"?
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
That's to be expected, of course. But putting a seasoned developer into a situation that just isn't going to happen not only wastes his time, but yours (the interviewer) as well. Interviews need to be about seeing how an applicant thinks and evaluating how well he can mesh with the team. Any sort of evaluation on basic syntax is something that should come beforehand either through checking the applicant's references or, better yet, their Github (or equivalent). Honestly I don't even consider a person unless they give me some sort of link where I can evaluate their work.
I could maybe see testing a junior developer to make sure he actually has some knowledge of a language, but even then when I'm hiring a junior developer I'm looking for potential.
Depending on the complexity of the task and the time allotted for the test, what gets churned out might not be of the best quality no matter who writes it. I'm a huge proponent of using frameworks instead of writing new code, of using patterns when applicable, and of test driven development. Being plunked down in an unfamiliar development environment and told to code without tools meant for the job is going to result in rough code no matter who you put there.
Really I'm all for kick-the-tires challenges; I use them myself after I have interviewed someone I believe is a good fit for the position. However, I test them in a way that shows me how they work in realistic conditions. I want to see their development process, how they interpret requirements, how they cope with an unfamiliar code base. I don't want to see if they know how to make javac not error out because I'm not using javac to compile my code (and everybody else in enterprise Java development shouldn't be either).
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
This sounds asinine. There is literally no situation where you won't have an IDE. Testing your knowledge on Java syntax is hardly going to evaluate your skills as a developer. A good company will want to know your experience with industry standard practices and common libraries. Seeing if you know the syntax of a language should be evident during a kick-the-tires tryout by letting you code like you should.
In my opinion you're probably not headed for somewhere you'd want to work. Any company that tests its applicants in scenarios that just aren't going to happen are likely being staffed by people who haven't adapted to changes in the industry. Anybody who wants to "evaluate" your programming skills outside of an IDE is probably somebody who thinks real programmers do it in vi (or emacs). Teams led by those kind of people are teams you want to stay away from if you ever want to advance your career.
I've been a programmer for a decade now and I've only ever been asked once to forgo an IDE during an interview. The guy who asked had been programming in C for 30+ years and didn't trust anybody else's code, including GNU. That's a huge warning sign to stay far, far away.
If the interview has already happened then I hope it went well. If not, call them back and tell them you feel that any sort of test under unrealistic conditions is not going to give them any real insight into your skills. If they push back, go look for a job somewhere else. It sucks to turn down an interview (or even a position) when you really need it, but having to work for any company that treats you like a junior developer fresh out of Comp Sci 201 is worse.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
You'll see a page with some technical output. At the top under the heading Graphics Feature Status will be some bullets. Next to CSS 3D should hopefully be some green text. If there isn't any green text then your computer's graphics capabilities aren't going to work with Scry (for now).
It's unlikely to be that your computer is too old, but rather that something about your graphics card/driver is buggy. Chrome will disable hardware acceleration when it detects some graphics cards because of really bad bugs in either the hardware or driver.
You can try this workaround and things might start working for you. However, Chrome blacklists things for a reason so disabling that could cause other issues. YMMV.
In other news, I've updated Scry to 3.6. This update should get pushed out soon.
Highlights:
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
Can you post what you see at chrome://gpu? If Chrome's not using hardware acceleration for 3D CSS I'm pretty sure you won't see the backside of a card. I'll have to really mull over how to fix that one.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
Just uploaded version 3.5.1 that addresses this. The controls are now outside the frame. The effect is actually quite fun to play with. Way better than before.
Probably not. The control menu has started to give a unified look to the popup. In addition, discoverability is higher now that controls are presented all together as opposed to multiple hotspots around the image.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
Emulation only gets you so far, though. Perfect emulation takes a massive amount of hardware so most emulation isn't exactly right. For example, original XBox games on the 360 are emulated, but via downloadable bits that handle the tricky emulation for that single title. Even then, emulation specific bugs crop up. Emulating 360 or PS3 games is pie in the sky; last gen consoles are still far too powerful to emulate.
Another option that wasn't really possible before is cloud streaming. Current gen consoles could use a service similar to OnLive to "emulate" last gen games. Performance would be highly dependent on network bandwidth.
The biggest hurdle, though, is companies have discovered that rereleasing back catalog games is profitable. Texture updates and some code shims to the new APIs are all that's really necessary to put an older game back out on a digital marketplace. As long as Sony and Microsoft can do this to their own titles and continue to receive pressure from other devs backwards compatibility is going to quickly become a thing of the past.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
I'm going to use an analogy. Be warned; like most analogies it isn't going to be 100% accurate but you should get the gist of it.
If you're sick and you go to the doctor do you question his diagnosis every time? If he says, "You've got the flu," do you respond, "Can you get someone else to give me their diagnosis?" Probably not.
The rulings forum here is very much like a doctor's office that's staffed by doctors. More often than not your question will be answered by a resident instead of a full MD, but it's not like that resident is a guy coming off his first FNM win after playing for a couple weeks. The answer you're given is highly likely to be correct, and, as already stated here a few times, will be quickly corrected by others if needed.
Remember, the rulings forum is a voluntary effort and you are not entitled to answers, correct or otherwise. Insisting on having a judge or RA answer or confirm answers for your questions is crossing a line and is a good way to get yourself on a lot of people's ignore lists. Instead, trust the system; you're not going to get accidentally diagnosed with the plague here.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
Turns out it's a Chrome bug. So if you'd like to see it fix, I encourage you to star that issue. DO NOT post anything like "+1" or "Me too." Just star the issue and it will move up the priority chain.
In the mean time, I'll look at alternative locations for the info button.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
3.3 had a big change to the layout and how certain transforms were handled. Turns out you were correct and 3.2 had sharp images on split cards. I've fixed this in the upcoming version.
CSS3 transforms are still in flux and, while widely supported, some parts aren't quite up to snuff in some browsers. Parts of Chrome's CSS transform handling really screws with images. So what happened?
To rotate the image we apply a CSS style with -webkit-transform: rotate(90deg). This of course also changes where the image is positioned in relation to its parent container. In 3.2, to get the image positioned back to where it was I applied a -webkit-transform-origin that shifted the image to the right place. Side effect was that the image was blurred slightly.
Now I'm not sure why I didn't try it before, but to fix the blurry images, I simply move the image container so it's again positioned on top of its parent container like it should be. Really simple fix that I should have tried before messing with transform-origin. C'est la vie.
Even then it wouldn't work.
The way the layout is now is thus:
So in the next update, which I just uploaded, has a couple new things. First off, cards are draggable again. Dragged cards won't hide unless you click the close button (which you won't miss). Also, the info toggle is now a button that you can't miss either. Easier to click too.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.
A side effect of webkit CSS transforms. Back when images were pulled from Gatherer I could specify a rotation and that was done on the server. Now, images all come in one orientation and Scry has to rotate the image client side with a CSS transform. Problem is, that transform blurs the image slightly. Annoying, but not sure what I can do about it.
I did find something in the chromium issues about a similar issue with text and rotation and a workaround was posted. I'll have to give it a try.
It's also noticeable when loading a lower resolution card (it doesn't quite fill up the box). Problem is, making the background a solid color causes the flip and transform animations to flicker considerably. Chalk it up to another webkit issue.
That's bugged me too. I might be able to do something about it.
[card=Jace Beleren]Jace[/card] = Jace
Magic CompRules
Scry Rollover Popups for Google Chrome
The first rule of Cursecatcher is, You do not talk about Cursecatcher.