Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm creating a board game in JavaScript (just to help learn the language) and I was wondering whether to use tables or divs (and CSS) for the board.
From what I understand, with tables the browser reads through the code twice. Once for the structure/layout and then again for the data.
I realise the page will only be loaded once so it won't make too much of a difference, but I was just wondering whether a game board would be an acceptable use of tables, since it's usually reserved for tabular data, or should tables be shunned altogether, even though divs require more code?
Using a <table> element to describe a game board is perfectly acceptable in my book, for example a chess or checkers board, Game of Life, etc, as (to an extent) the game state can be both represented-as and interpreted-as tabular data.
Use table-layout: fixed to have a table that uses a more efficient layout algorithm that's a lot faster and predicable, however can lead to a poor layout unless you've manually optimised it (usually by setting manual column widths).
The algorithms used are described here: http://www.w3.org/TR/CSS21/tables.html#width-layout
I think this question mainly depends on what you plan on doing with this board game: Is it for ONLY practicing JS (meaning no one else will see it) or will it be later used for other people to utilize it?
In my opinion, we all need to start somewhere, so it is acceptable to use a table in your creation of the board game if you are looking to experiment. In fact, you shouldn't need to worry about optimization if you are only using this to enhance knowledge and for your own personal use.
However, in another offset opinion.. I would suggest you begin to look at the idea of using divs/uls/lis to create a table, as this practice is really invaluable and it is honestly a good idea to begin grasping this idea early rather than later. It will also give you the feel for how CSS can represent multiple things in various ways and how you can also manipulate CSS to really do whatever you want with it.
If you are planning to have this game made public so other people can play, you will want to look into what will optimize the speed or performance of your website. This is where the links that were provided could be of use. In all reality, everybody has their own opinion on this matter and it will be a constant fight until there is solidified evidence on this matter. I would imagine by the time they decide which layout is better, CSS will already be upgrading and optimizing to its fullest capabilities.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I had a conversation with my CTO regaring using CSS Grid, and the question that I heard the most was “Why use grid, that’s not supported in old browsers if we have to write flexbox fallbacks anyway? Why don’t we just build with flexbox?”
And it got me thinking. A big advantage of CSS Grid for me is writing less code. But if I have to write fallbacks, I’m effectively writing grid code AND flexbox code, which is more work. So that argument kinda makes sense I guess?
What would you answer to that?
Here is some arguments why.
You could do a lot more with design. Think about all the workarounds you need to implement in order to have something simple as 100vh... Your designers will be happy if they have you on their team.
Lot less duct taping solutions, see above.
New features makes your code better, maintenance will be a lot better, you code in general will be more clean. This actually means less work in the feature.
Performance, browsers that support new features will have lot less code to use, this is not true ofc for every new feature out there.
More work with fallback solution, yes, that might be true. But if you are always writing the same fallback solutions to the same features then you are doing something wrong, search the web, there might be a solution already there, if not make your own internally and reuse it on other projects, thus you will have to make a fallback solution only once.
You want your developers happy, if there is a way to use new features (and there is almost always a way), you should use it. Motivation kind of a thing.
If NOT then those features will never get used anyway since people will stick the old ways thus there is no need for browsers to implement in the new versions because guess what no one is using those new features thus we don't need them. But we all know we need them.
New features will eventually becomes standard (if we actually use them), you want to have team that is already proficient in those new technologies, thus you can sell yourself better to the client.
As for grid css layout, check this one --> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/CSS_Grid_and_Progressive_Enhancement
Also, this kind of question is better fit for the Quora or something similar, not stack.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm not sure where to begin, but my goal is to to create a 2D simulation game that allows the user to create formations using points, or dots, on the grid. I wanted the game to allow the user to direct the points on the grid to their next location, or set of locations, in a continuous simulation from the first formation to the last in chronological order.
Like I mentioned earlier, I am brand new to coding and wanted to know what specifically should I be looking to learn to create this? Also if you have suggestions on what I should use to create this such as Flash, Html5, or something else please let me know.
Are you trying to make Conway's Game of Life?
As far as good beginner game engines go my first couple of games were in GameMaker. I understand the reputation it gets about it not having "real programming" but if you are learning to write code I actually think this works great. No it doesn't have syntax like code does, but it does require you to learn programming logic and that is what is important. Syntax isn't that tricky and you can look it up. Logic and structure, that's hard.
I don't know much about FLash other than that it is kind of a sinking ship and losing support. If it's between javascript and that, go Javascript. When you say
HTML5 or Java, you do not make games in HTML5. If you have an HTML5 game engine like Impact, it's actually javascript code you are writting. HTML5 is just putting the game window in a web page.
I haven't messed with PyGame much, but Python is a fantastic beginner language and I have heard this works for small things like what you want to do.
Love2D gets used for projects like yours a lot. Don't have experience with it myself but you could take a look at it.
I have used Unity a lot for my projects big and small. It's a big learning curve but if you want to learn how you could make "big" games, this is how you should do it. Tons of great beginner learning materials and support, just expect to go through several tutorials(which you should do anyways with whatever you pick) before you can get started.
So you have a start pattern, and a target pattern, and the user must move the points by, say, sliding them along the grid lines, until the target pattern is attained... I think the easiest would be Corona (https://coronalabs.com/, free and excellent docs). It has a very simple game engine which is based on Lua programming language, a very simple language that is also very powerful and versatile such that it will allow you to jump in and support complexifying your game as you learn. Corona is built so you don't have to worry about all the intricacies of getting the code onto the device etc, it has a device emulator so you can test on your desktop. You just focus on creating your callbacks and logic and imagery, they will get used at the appropriate time.
The concepts you will need to develop your game:
- setting up the initial grid and pattern
- drawing lines (for the grid) and circles (for the "points) (presumably, different colors)
- handling a swipe
- updating the state of the grid so you know where the points are
- determining if the target pattern has been met
- keeping score (time used, number of moves required)
- start-over (prematurely with confirmation by user, or when target reached)
Install Corona, look at its intro to Lua, start playing around with it, starting with really simple stuff, actually best is to take existing examples that come with Corona and try to modify them to do something different and gradually diverge from original. The Corona docs and examples are excellent, there is a very active community, tons of youtube videos by avid game developers on tricks and techniques, and corona questions on stackoverflow get quick answers.
Have fun!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've downloaded the source code of my favourite program.
At school they taught us that the entry point is the main.c(pp) and then follow the headers, but I realise that is not always the case. In some cases there isn't a main or It deep buried somewhere where I can find it.
And the documentation in most cases describes only how to compile, what deps you need and etc.
Bottom line, you've downloaded the code, untar'ed it.. now what?
I don't have any particular example to ask (help) for, so if you have any example to help me it's welcome
Reading code is often more cumbersome than writing code. This inquiry does not have a single answer and you should explore multiple opinions and see which works best for you. One practice you shouldn't engage in is reading the code start to finish. This will lead to eye bleeding and mind-numbing frustration. So don't approach it like a book, since reading it like one, cover to cover, is very inefficient. Reading is not learning. Applying what you read is learning. One key point to remember is don't get discouraged. You will be hard pressed to find a programmer that can quickly pick up on a foreign, large base of code quickly.
The best 'book speed readers' skim through something they are about to read a form an outline in their head. They take mental notes of logical sections and paint a thin picture about what to expect. When your brain has seen something before, it is more likely to be engaged with the material. I would skim the header files as a way to form this outline. If there are no header files, then try to skim quickly though class interfaces and take note of which are connected and what is their general purpose.
Make a second pass through the sections of code that interested you. Try to identify a subsystem of the code and make a second, more detailed pass through it. I personally would look for connected components for identifying the subsystems (look at imports). Jot down some of the data structures used and associated algorithms and design patterns. Make associations between them and try to understand why they were used.
Lastly, don't be content with just reading the code. Since you are looking at open source, challenge yourself to add a feature. Take one of the subsystems you were intrigued with and add on to it. If this still intimidates you, take the last bullet a step further. Make a quick flow chart detailing the flow of the code. Bust out your favorite IDE and leverage breakpoints around areas you don't understand the flow. Try to put yourself in the mind of the designer and think why he made certain decisions as your stepping through the breakpoints. Bottom line: It is easy read something and think you understand it. But, doing is where the real learning takes place. You will find yourself asking more questions and researching more into the code when adding a new feature. Having this direction is all it takes sometimes.
If the source code leverages an OOP solution, I would strongly recommend studying a Design Patterns book. I was going to include Design Patterns as a bullet, but I didn't know if the source code you are viewing uses an OOP approach.
Hope this helps! This was the approach I undertook when learning to code a couple years ago.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Hey everyone I just bought the master cs5 suite mostly for design purposes, and now I have a lot of peoPle telling me I should start using DW instead of hand coding my HTML/CSS because it will speed up my production and it's what all design shops use and is an industry standard . I was curious if this is accurate and how much would it really speed things up?
I (personally) disagree. I use DW in CS5 for code editing view only (it has the best markup/code highlighting I've found); the generated markup is not great, so I don't use it, nor am I highly trained in the workflow it entails. A lot of designers will not understand hand coding markup, but that's usually because they don't understand how to or don't care to do so because it's not what they get paid to do.
However, if you're working on (a) lower level, you have a better understanding of your markup/styles/code. It may take slightly/significantly more effort (depending on your abilities hand coding), but I personally think it's worth the effort in many cases. However, I am not a piece worker nor am I paid on deadlines.
There are other reasons I use DW (WebDAV support, searching capabilities), but I will likely never use it to author my markup. Also note I don't pay for it.
Used unwisely it won't speed it up at all. You'll spend more time pulling out DW's extraneous code. Use parts of DW that will make you faster like snippets (for storing snippets of code you use frequently) and find and replace (using f&r with regex is a very useful skill). I use it to cram in table markup quickly (for data tables). Dragging files over for internal links is quite nice and the keyboard shortcuts help (you can create custom ones).
That said, I like the product at work. Check in and check out has been very helpful there with multiple coders/designers.
So, there are plenty of parts in DW that will speed up your hand coding. Root them out.
Dreamweaver CS5.5 made a lot of improvements over previous versions. As a designer you may appreciate Live Preview and the design integration's. As a coding IDE, it's still considered sub-standard and many developers choose to go another route. I use PHPdesinger 7 for ~$70, its got in-line xdebug integration and pretty good intellisense for PHP, CI, and jQuery. I use DW5.5 and PHPdesigner and I find it's far less bloated then Dreamweaver for what I use it for, coding with PHP/Jquery and web API's. I also feel that it's closer to how I worked before using advanced IDE's like this, coding on my Macbook with Coda. But if your designing web pages you may like Dreamweaver better.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm pretty sure most of us are familiar with the concept of a project's requirements changing after it starts, this becomes more and more of an issue the less the client knows about how things work and the closer you work with them.
How then can I design a system (specifically a website but general advice will probably be best here) so that smallish changes can be made, are there any programming strategies that deal with this issue?
All the normal oo principles apply here, reduce coupling, increase cohesion, don't repeat yourself etc. This will make sure you have a flexible and extendible code base.
Apart from that don't try to preempt change. Apply YAGNI (You aint gonna need it) everywhere. Only build stuff you know your users need. Dont build stuff you think you're going to need. You're more likely to guess wrong and then you've got a bunch of code that's probably only in the way.
I think the biggest thing is to make sure you have a comprehensive test suite. That way you can make changes confidently when needed and know when it breaks.
Having no experience with PHP, take this with a pinch of salt.
But it's all about knowing change will come. So when you are coding and start wanting to hack things to get them done, stop and think "what if I need to change this again?".
Now, I know php is a scripting language, but you must be able to library off code right? Thats the best thing to do, keep the UI (the web page) as LIGHT as possible, for the most part 1 or two method calls.
If you have fancy rendering logic, library it. Create a nice look that may be common? Look at what might change (colour scheme etc.), library it. You're already putting all your core code into libraries though right? ;)
If you always work on building your library, all you need to then do when the change request comes in is "find the right book for it".. Whats cool about what we do is that if the book is well written, you can easily add annotations to it ;)
This is basically what I am doing at work at the moment, my "project" is to build the platform that future apps will be working on, so this is really my main focus. :)
Update
Mendelt made a good point on applying YAGNI, with all of the above, don't just write stuff to library it but if you think for a second that the sexy little table you just created (because a client wanted it) might be used again, then it's time to think about making it more usable. Some obscure function for a one-off client should be done ad-hoc.
Well, I'd try to tackle this problem from the other side:
More communication with the customer/user.
I have been there myself, programming things that were not wanted or not properly communicated and having to redo lots of code. It would have been prevented with more communication or rather: with more of the right communication.
Aside from that:
Allow Users to change the color and ask them now and then, where to place a button and the probability, they will be satisfied with this "great level of control" is quite good. And then they won't want you to redo real features. Yes, I am sarcastic about this.
I suggest using a tried and tested framework for your language of choice. Most good frameworks will have been designed to accommodate a multitude of scenarios.
First, you should identify the aspects that will have a high change probability. These aspects should be 'abstracted out'. A classic example is the style of your website (i.e. through css). But you could even so define a 'presenter' class that lays out the specific elements of a web page.
The hard thing is making a correct estimate of the change probability. But that's up to you :)
This is where frameworks come into play.
If all the baseline, background, business-as-usual is in the framework, then your application is the extensions, special-cases and add-ons.
The framework is already designed and built for change. Your stuff is the change that the frame was designed to accept.
When change occurs, you will respond to change with some combination of modifying the framework configuration and rewriting your stuff that plugs into the framework. You cope with change by not focusing on the default, background stuff. Delegate that to someone else -- the framework authors.