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 10 years ago.
Improve this question
I'm really anal about what I name my classes, and I need an adjective for both something that is only allowed to happen once, as well as something that is allowed to happen multiple times.
examples:
wordthatmeansitcanonlyhappenonceTrigger
wordthatmeansitcanhappenmultipletimesTrigger
OneShotTrigger and RecurringTrigger
For one time: nonce.
OneShotTrigger
RepeatableTrigger
How about
SingularTrigger
PluralTrigger
Also, I don't think this is exactly what you're getting at, but this may be related to Idempotence.
With tongue ever so slightly in cheek, how about:
BirthTrigger - you only get born once.
BirthdayTrigger - but you can have lots of birthdays
singleTrigger
multiTrigger
-Adam
I usually use 'OneTime' for the single shot, and nothing particular for the multiple case.
It's not really canonical though...
onceTrigger, manyTrigger
oneTrigger, manyTrigger
Also, sometimes I just don't name one (once or many) and name the other (once or many) to make it stand out. Maybe you could just put an 's' on the end of one and not the other.
I just use "OneTime." Maybe it's a poker thing.
You could call them WyclefJeanTrigger and TimMcGrawTrigger. ;-)
Singular or Once
SingleShot and Repeating are commonly used.
MonochronicTriggerPolychronicTrigger
I know this is an old post, but I have a suggestion not yet mention.
As a pair
UnrepeatableTrigger
RepeatableTrigger
work well.
Though, much like Microsoft, when using the registry to ensure that things happen only once on startup, they use the term RunOnce.
So instantly, I would recognize
RunOnceTrigger
as being something more maintainable and clear than
OnceTrigger
OneShotTrigger almost sounds desperate "we've only got one shot at this and if it fails we're up the creek without a paddle".
Monochronic and Polychronic do not seem to be relevant, as mentioned here.
Monochronic and polychronic time
systems are two terms used to refer to
time and its influence on society.
monochronic time
system means that things are done one
at a time and time is segmented into
precise, small units.
Here are some other adjectives.. I particularly like Unrepeatable just beause it sounds like you're talking about a family taboo, or Voldermort.
http://www.macmillandictionary.com/thesaurus-category/american/Happening-only-once
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 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.
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 9 years ago.
Improve this question
I prefer to write my HTML clear, so I may use empty lines here and there - example:
<div>
<!-- Seasons -->
<table class="giantTable">
...
</table>
<!-- Prices -->
<table class="giantTable">
...
</table>
</div>
Today my new workmate told me that this is bad for SEO,
because Google would need more time for parsing the site and may abort with a timeout.
I never heard about this,
shall I really write Spaghetti-Code again?
Google do use page-load and rendering time as one metric (of over 200!) for determining your page-rank, so to an extent your colleague is right (although timeout's are not the issue - he is wrong on that).
However, you can have the best of both worlds :) Write your HTML as you normally do, and then minify it before deployment.
Note that there are a number of tools for analysing your site performance (both online, and as browser plugins - e.g. YSlow), and it's a very sensible thing to do. You can have numerous bottlenecks in your web-site, and can often get some quick wins that significantly improve the responsiveness of your site.
As always with optimisation though - measure first! Don't just randomly implement supposed improvements until you have measured the bottlenecks, and then confirmed the improvement is an improvement.
The sentiment isn't entirely off. Google does now consider the speed of your pages as a factor, and excessive white-space in code can increase payload size. Google themselves recommend minifying your code ( https://developers.google.com/speed/docs/best-practices/payload#MinifyHTML ), and this can be done without too much overhead on the web server.
I find the biggest culprit in dynamic websites comes from using loads of space in the middle of for/while loops, so cutting down on that can make a big difference. Also, try using tabs instead of spaces and you'll cut your white-space big-time.
Even if this were true (which I've never heard before however RBs point above makes a good point), there are many other things that contribute to your page ranking way more than what that would.
Google made an awesome SEO guide which I always check out, its really pretty and easy to read as well, what with all the pictures of Robots. Its definitely worth checking out - Google SEO Guide
It isn't bad at all, they ignore white space. Otherwise everyone would be trying to write code all on one line
http://jamesmartell.com/matt-cutts/is-excessive-whitespace-in-the-html-source-bad/
This document describes how to do SEO for Google (it is quite extensive). A first glance over all the pages doesn't say anything about compressing your HTML.
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.