search

mrmikemcguire / Blackjack

1 stars 6 forks source link

Some ideas for implementing a blackjack framework #1

Closed gabesullice closed 8 years ago

gabesullice commented 8 years ago

Okay, I think I got a bit carried away, but the nugget of how I would deal with dealing cards is in here. It all might be too much too soon/fast. On the other hand, I think it will feel very familiar after doing all your OOP Java stuff and if we can look past all the syntactic ugliness that is Javascript.

I'm still iffy on using divs for this. I try to use as few as possible from day to day as they're a bit of a developer crutch (admittedly, they still are often the only way to do something in a design, but hopefully that will fade away with new CSS standards).

Divs have become somewhat of an antipattern in the last couple years. The reason for this is that they're not very semantic. That is, HTML is meant to create structured content for machine-like consumption. A computer should be able to say, "this is a paragraph because it's a <p>. This is an <h1>, so it must be a title for the content after it. This <article> tag is grouping this piece of information together so it's probably not related to this other <article> (think a blog feed)" We do this to make our sites more accessible, primarily so that screen readers can understand it. As a side effect, it means Google can parse it or an app like Instapaper can slurp it up to be reformatted in a different context.

The div tag is the most generic thing out there and really adds very little to the context of the content that it contains. Most of the time, its only purpose is to group something together so it can be moved somewhere else visually on the screen. But, we already have that in the form of classes - and classes are far more flexible. They can be mixed, matched, overridden and composed. Consider:

<div class="left">
  <div class="red">
    <item />
    <item />
    <item />
  </div>
  <div class="blue">
    <item />
    <item />
    <item />
  </div>
</div>

vs.

<item class="left red"/>
<item class="left red"/>
<item class="left red"/>
<item class="left blue"/>
<item class="left blue"/>
<item class="left blue"/>

What would one have to do to put all the blue items on the right? Or make every other item blue or red? Or perhaps have both alternating to create a checkered pattern? In all of those cases, the HTML on top would need to be completely restructured, but in the second scenario you just flip the classes around. Since no one is really hand writing HTML anymore - they're just writing templates for data to be shoved into - classes are the way to go. We can treat classes like data, i.e., you can have your backend swap out the classes at will from page to page but you can't have your backend dynamically restructure your HTML. The latter would be far to slow to process and impossible to theme at even a modest scale because there would be no patterns to target from page to page.

</web rant>

mrmikemcguire commented 8 years ago

Wow, thanks for the detailed explanation - you make a great teacher! What you say about divs vs classes makes perfect sense, and I'll be able to communicate that clearly to the students now. Mullen is having its Open House today, so I probably won't get a chance to look at the actual code until tomorrow, but I'm excited to both see your ideas as well as better understand how you professionals comment on code in general. I feel pretty comfortable pushing and pulling stuff to/from GitHub now, but merges still scare me a little.

Mike McGuire

Director of EdTech

Computer Science Dept. Chair

Mullen High School

(303) 761-1764 Ext. 3411

“Educating in the Lasallian Tradition”

On Sat, Oct 24, 2015 at 10:22 PM, Gabe Sullice notifications@github.com wrote:

Okay, I think I got a bit carried away, but the nugget of how I would deal with dealing cards is in here. It all might be too much too soon/fast. On the other hand, I think it will feel very familiar after all doing all your OOP Java stuff, if we can look past all the syntactic ugliness that is Javascript.

I'm still iffy on using divs for this. I try to use as few as possible from day to day as they're a bit of a developer crutch (admittedly, they still are often the only way to do something in a design, but hopefully that will fade away with new CSS standards).

Divs have become somewhat of an antipattern in the last couple years. The reason for this is that they're not very semantic. That is, HTML is meant to create structured content for machine-like consumption. A computer should be able to say, "this is a paragraph because it's a

. This is an , so it must be a title for the content after it. This tag is grouping this piece of information together so it's probably not related to this other (think a blog feed)" We do this to make our sites more accessible, primarily so that screen readers can understand it. As a side effect, it means Google can parse it or an app like Instapaper can slurp it up to be reformatted in a different context.

The div tag is the most generic thing out there and really adds very little to the context of the content that it contains. Most of the time, its only purpose is to group something together so it can be moved somewhere else visually on the screen. But, we already have that in the form of classes - and classes are far more flexible. They can be mixed, matched, overridden and composed. Consider:

vs.

What would one have to do to put all the blue items on the right? Or make every other item blue or red? Or perhaps have both alternating to create a checkered pattern? In all of those cases, the HTML on top would need to be completely restructured, but in the second scenario you just flip the classes around. Since no one is really hand writing HTML anymore - they're just writing templates for data to be shoved into - classes are the way to go. We can treat classes like data, i.e., you can have your backend swap out the classes at will from page to page but you can't have your backend dynamically restructure your HTML. The latter would be far to slow to process and impossible to theme at even a modest scale because there would be no patterns to target from page to page.

You can view, comment on, or merge this pull request online at:

https://github.com/mrmikemcguire/Blackjack/pull/1 Commit Summary

  • Implement blackjack JS framework

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/mrmikemcguire/Blackjack/pull/1.

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, contact the sender by reply email and destroy all copies of the original message

P Please consider the environment before printing this e-mail.

mrmikemcguire commented 8 years ago

So, I merged your commits with mine, but I'm afraid that it doesn't run. Am I missing something?

Mike McGuire

Director of EdTech

Computer Science Dept. Chair

Mullen High School

(303) 761-1764 Ext. 3411

“Educating in the Lasallian Tradition”

On Sat, Oct 24, 2015 at 10:22 PM, Gabe Sullice notifications@github.com wrote:

Okay, I think I got a bit carried away, but the nugget of how I would deal with dealing cards is in here. It all might be too much too soon/fast. On the other hand, I think it will feel very familiar after all doing all your OOP Java stuff, if we can look past all the syntactic ugliness that is Javascript.

I'm still iffy on using divs for this. I try to use as few as possible from day to day as they're a bit of a developer crutch (admittedly, they still are often the only way to do something in a design, but hopefully that will fade away with new CSS standards).

Divs have become somewhat of an antipattern in the last couple years. The reason for this is that they're not very semantic. That is, HTML is meant to create structured content for machine-like consumption. A computer should be able to say, "this is a paragraph because it's a

. This is an , so it must be a title for the content after it. This tag is grouping this piece of information together so it's probably not related to this other (think a blog feed)" We do this to make our sites more accessible, primarily so that screen readers can understand it. As a side effect, it means Google can parse it or an app like Instapaper can slurp it up to be reformatted in a different context.

The div tag is the most generic thing out there and really adds very little to the context of the content that it contains. Most of the time, its only purpose is to group something together so it can be moved somewhere else visually on the screen. But, we already have that in the form of classes - and classes are far more flexible. They can be mixed, matched, overridden and composed. Consider:

vs.

What would one have to do to put all the blue items on the right? Or make every other item blue or red? Or perhaps have both alternating to create a checkered pattern? In all of those cases, the HTML on top would need to be completely restructured, but in the second scenario you just flip the classes around. Since no one is really hand writing HTML anymore - they're just writing templates for data to be shoved into - classes are the way to go. We can treat classes like data, i.e., you can have your backend swap out the classes at will from page to page but you can't have your backend dynamically restructure your HTML. The latter would be far to slow to process and impossible to theme at even a modest scale because there would be no patterns to target from page to page.

You can view, comment on, or merge this pull request online at:

https://github.com/mrmikemcguire/Blackjack/pull/1 Commit Summary

  • Implement blackjack JS framework

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/mrmikemcguire/Blackjack/pull/1.

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, contact the sender by reply email and destroy all copies of the original message

P Please consider the environment before printing this e-mail.

mrmikemcguire commented 8 years ago

Wow, the email I sent you automatically added a comment in this GItHub thread. How did it know to do that?!!!

mrmikemcguire commented 8 years ago

OK, I have it displaying now - not sure what was up with that. I notice that some of the variable names are underlined. Does that signify something from you or is that a feature of Webstorm?

Mike McGuire

Director of EdTech

Computer Science Dept. Chair

Mullen High School

(303) 761-1764 Ext. 3411

“Educating in the Lasallian Tradition”

On Sat, Oct 24, 2015 at 10:22 PM, Gabe Sullice notifications@github.com wrote:

Okay, I think I got a bit carried away, but the nugget of how I would deal with dealing cards is in here. It all might be too much too soon/fast. On the other hand, I think it will feel very familiar after all doing all your OOP Java stuff, if we can look past all the syntactic ugliness that is Javascript.

I'm still iffy on using divs for this. I try to use as few as possible from day to day as they're a bit of a developer crutch (admittedly, they still are often the only way to do something in a design, but hopefully that will fade away with new CSS standards).

Divs have become somewhat of an antipattern in the last couple years. The reason for this is that they're not very semantic. That is, HTML is meant to create structured content for machine-like consumption. A computer should be able to say, "this is a paragraph because it's a

. This is an , so it must be a title for the content after it. This tag is grouping this piece of information together so it's probably not related to this other (think a blog feed)" We do this to make our sites more accessible, primarily so that screen readers can understand it. As a side effect, it means Google can parse it or an app like Instapaper can slurp it up to be reformatted in a different context.

The div tag is the most generic thing out there and really adds very little to the context of the content that it contains. Most of the time, its only purpose is to group something together so it can be moved somewhere else visually on the screen. But, we already have that in the form of classes - and classes are far more flexible. They can be mixed, matched, overridden and composed. Consider:

vs.

What would one have to do to put all the blue items on the right? Or make every other item blue or red? Or perhaps have both alternating to create a checkered pattern? In all of those cases, the HTML on top would need to be completely restructured, but in the second scenario you just flip the classes around. Since no one is really hand writing HTML anymore - they're just writing templates for data to be shoved into - classes are the way to go. We can treat classes like data, i.e., you can have your backend swap out the classes at will from page to page but you can't have your backend dynamically restructure your HTML. The latter would be far to slow to process and impossible to theme at even a modest scale because there would be no patterns to target from page to page.

You can view, comment on, or merge this pull request online at:

https://github.com/mrmikemcguire/Blackjack/pull/1 Commit Summary

  • Implement blackjack JS framework

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/mrmikemcguire/Blackjack/pull/1.

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, contact the sender by reply email and destroy all copies of the original message

P Please consider the environment before printing this e-mail.

gabesullice commented 8 years ago

That's webstorm. Yeah, I'm sure there are some bad variable names in there, like this.name vs this.id, which I renamed at some point and probably forgot to update.

Most of the code paths are just empty and/or pesudo-code. The idea was less to present a working example, but to outline of a framework that you could put your logic into and riff off of. Also, to demo Javascript OOP.