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 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 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
Soon I will need to give a presentation on my honours project for the engineering faculty and a large group of engineering and technology students at my university. While all the the people attending will be technical-minded, not all of them will be programmers and most will be from other engineering disciplines.
I have given presentations before, and I am confident speaking to a crowd, but I realize now all the presentations I have given before have been to fellow CS/SE majors and teaching staff. I wonder if my presentation style assumes that I am presenting to other software geeks, so they will know what I am talking about and I can put on a more interactive demo involving the audience.
My honours project isn't terribly complex or theoretical, I have a prototype C# Winforms app but it is designed to be extensible and operate with different data sources (ODBC or WS) in the future, and some research to how it could be extended with a rule engine and DSL and turned into a marketable product. The organization that is testing my prototype is saving tens of thousands of dollars a year by automating a critical business function.
I had planned to show off how extensible it was by some live coding and UML-style diagrams. I really enjoy doing demos and live coding but I don't know if that kind of presentation will be as accessible to non-programmers, and I am worried if I get too geeky and technical I may alienate the audience and judges.
What are the effective techniques you have found to present software projects in a way that is also interesting to non-programmers
When I was working on my doctorate, the faculty gave us this rule for seminars - and it has proved very useful since:
Tell 'em what you're gonna tell 'em. (E.g., brief introductory problem
description and results abstract)
Tell 'em. (E.g. technical details comprising the bulk of the time)
Tell 'em what you told 'em. (E.g. brief summary and conclusions)
Open the floor for questions.
In your position, I would take about 10-20% of your allotted time to do #1 in a largely non-technical way. So you might describe the business function your code automates, why that's important, what things were like before and after applying your solution, how it's saving money, that kind of thing.
Then I'd launch into a highly technical discussion aimed at the CS/SE crowd. Even if the rest of the folks don't understand it and their eyes glaze over, your introduction at least will have given them a sense of what it's all about, and they might recognize a bit here or there.
For the third part, I'd briefly recap the problem and describe how you solved it in non-technical language, and then do your live-coding extensibility whiz-bang demo. Even if the non-CS/SE folks don't understand the demo, they'll see eye candy flying by and your professional peers and faculty all nodding and smiling, so they'll think it's cool.
I once attended a seminar by a guy who won the Nobel Prize for applying chaos theory to chemical systems. He applied this approach, so even though all the non-theoreticians like my fellow organic chemists and I were all completely out of our depth, the fact that the theoreticians were all excited left us feeling like it was a great seminar even though we didn't have a clue about what he'd said.
To appeal to both audiences, I sometimes give the technical explanation and then follow it up with my "in English, please" explanation. CSI and other dramas with science in them do this all the time, to good effect.
In other words, [insert plain english explanation here].
Lets attack this as a refactoring problem.
ie Instead of adding more to your presentation, Is there a way in which you can take stuff out?
For example I don't think showing off that your demo App can use multiple data sources is essential, much less grants for you to program right there during the presentation.
I know it took care in the design of your app to reach that point, but still most people are more interested in the OUTPUTS not the INPUTS of an app. And even more in the BENEFITS of said app.
Some guiding points:
Make the presentation about them. If the audience has felt the pain that your program solves, remind them of that pain. If they are other researches like yourself then ask them to put themselves in the shoes of the organization you helped.
Compare the old way vs the new way of doing things. Why is the new way more efficient? Will it lead to more sales? will it reduce inventory? or save money? Will someone lose his/her job because your solution makes his task irrelevant. Note: When making technological presentations I've observed is important to address what happens to the people that was doing the task previously. Fortunately most of the time people don't lose their jobs, in most cases the same people can manage a much larger volume of work thanks to
Technology.
Show results. What are the real results your demo company has observed?
Use meaningful visuals. If you could make some animations that explain your algorithm even better.
Tell your point at the beginning and the end. Most people will forget what happened in the middle so make sure to tell the most important thing at the beginning and the of your talk.
Practice, Practice. Yeah it sounds ridiculous but do your whole presentation in front of a mirror or video recorded at least twice. The more the better.
Don't give one of the most important presentations of your life without a rehearsal.
Breath and be positive you will do fine :-D
PS: My suggestions are derived from this webpage. It has guided me several times:
6 Stimuli to reach the old brain
You're already working on knowing your audience, which I think is awesome, you just need to take it a step further, and ask yourself, if I were x person in the audience, what would I get out of this presentation.
I'd question the validity and how much effort should go into the technical/coding demo, if the group you're presenting to is never likely to use your specific implementation. It may be more important to portray how you approached the extensibility, so that you garner ideas within the peers on how they can approach it in the future, as well as hit on points throughout that are important to all of your audience members, and maybe shortcut the demo a bit to just show that, yes, indeed it does work.
I don't know about you, but personally I've always got more value out of these types of presentations based around how the project appeals to everyone, how you are managing to save tens of thousands of dollars per year for this company, theoretically why other companies might want to use it as well, what is the market and other factors, what were the giant technological hurtles you had to overcome, even if it's a simple project, there were things you must have thought about ahead of time to avoid and prevent you from getting backed into a corner.
I think if you're a really good presenter, and the purpose of the presentation is to be broad and appealing to the entire group, and not a talk on the chaos theory and application to chemical systems, which has that stated purpose, you should appeal to the lowest common denominator of the audience, and the entire audience can be entertained and appreciate what you have achieved at every step along the way, and to do this, they don't necessarily have to understand every step taken either.
I've been in the same situation
(presenting a software engineering/image processing/recognition project in an EE faculty competition).
Start with the issue (the problem)
Then the background (a BIT of technical background)
The solution:
Start with block-charts (all engineers read those)
Then explain the technologies and how briefly - how complicated the implementation was
(don't underestimate the complicated part - otherwise you may make your work seem to simple to engineers from other fields - they won't appreciate your effort)
Results:
Show short visual examples (try to make them intriguing)
(short code examples can go here)
Short user interface demo
Show impressive graphs
Bibliography, thanks, possible future improvements/research
Questions (if the forum is large, tell them in advance that the time for questions will be at the end)
General advice:
Practice presenting (over and over)
Leave 45-60 seconds per slide
No more than 5 points per slide
1 line per point
Add jokes
No animations except for demonstrating complicated issues faster
Use clear fonts (Ariel or Calibri for regular text, 1 different font for titles)
Use high contrast colors
(bright on black or dark on white if you must - no dark on dark or bright or bright)
Well first of all, I would suggest talking to your faculty advisers about what they expect from your presentation. If there's any question about how you should balance technical details understandable to only CS people versus more general concepts understandable to the larger audience, I think it would really help to get input from those who will be evaluating you.
One thing I really like to see from a presentation is a "take home message". What is the one thing you want everyone in that audience to remember long after they've left the room? Tell them the take-home message at the very beginning. Tell them you will spend the rest of the presentation explaining why they should care and why they should believe you. Even if people get lost in some of the technicalities, if you at least drive home that one message, you've delivered one thing to a lot of people.
Another suggestion: don't forget about format. Presentation slides should be readable from anywhere in the auditorium/lecture hall. Don't overwhelm people with too much text on one slide. Keep bullets short and easy to scan. Do you want people spend their time reading your slides or do you want them to listen to what you have to say? Don't use acronyms, but if you must, explain what they mean--and put the definitions on your slides--unless you are sure they are common knowledge. If people are sitting there wondering what the heck that acronym means, they aren't listening.
As to whether you should show actual code or do live coding, my gut feeling is that you shouldn't unless it's absolutely critical to the point you're making. If your project were actually about some coding construct (e.g., if you had invented the concept of an "extension method"), okay, it would make sense to get into some actual code. But it sounds like the significance of what you've done is definitely up a level from that. You might want to show how little code it takes to, say, hook up a different data source, but I wouldn't actually get into walking through the code itself unless you feel you can't make your point otherwise. One thing I probably would like to see if I were in the audience is a demo of your code in action. Show me what is does, and tell me why that's cool.
I hope it goes well!
Here is my advice:
Be clear who your audience is and what your message is - Are you trying to impress six faculty members who are marking your project, or proving you can entertain the whole audience.
Have a Contents page early on - that way the audience know what to expect.
Put the geek stuff in an appendix to your main presentation. That way you can dip into it ,for questions, but you will not loose the main point of your talk.
Make sure your presentation flows and tells a story - limit slide numbers and don't clutter them e.g. project goals,possible uses, design challenges, software choice, what you did (limit techie), results (demo), results and limitations, next steps, questions.
Have a Conclusions page at the end -- make sure you circle back and cross refer to your original contents page.
Leave 15-20% of your time for questions. This will reveal what the audience is interested in, and allow you to display a deeper understanding of the topic i.e. only do live coding if they ask for it.
Rehearse out loud even if you feel stupid doing it.
Good luck.
A few tips
Use a common technical language. only use terms that the hearing will recognize.
It links what you expose yourself, with examples recognizable by the audience.
you can also read these great articles.
11 Top Tips for a Successful Technical Presentation
Tips for a Successful Technical Presentation
Bye.
Mix and match some topic everybody know. It has helped me to theme slides with images ranging from the Divine Comedy to the Simpsons I don't know how formal is your presentation but it's a common constructivist technique to hook on something your audiente already know to show your point.
I once attended a presentation of Larry Wall where he explained Perl 6 features using examples from golf mixed with the Lord of the Ring.
What I do is to talk analogies, try to convert to real world the terms you are explaining.
BTW, Why are you talking about software tech aspects to non tech people?? You have to target the content to your audience first. Who is your main audience?? The techies or non techies, choose one.
Regards,
I'd be inclined to not use code (unless you actually have to), and use some form of generic (and straightforward) pseudocode.
Also, if you are doing the talk with prompt cards, put 'Breathe!' at the top of the cards. It helped me...
Focus on the user interface (aka how it makes their lives easier) and how it is different from similar products (why they should listen.)
I think Simon Peyton Jones gives excellent talks. See the How to give a good research talk section on this page. In particular, check out the video of his talk about the subject linked to in that section. You can find other videos out there of his talks on Haskell, functional programming, etc. to see how he practices what he preaches.
Please listen to the following podcast : Manager Tools - Presentation basic
It will cover all the basics you need to do effective presentations.
Now when doing project presentations do the following:
Create a High Level Architecture model ... see this model you can probably do better (note: the model image is from my blog.).
Create a High level requirement list
Create a application workflow process diagram (once again pretty colors, arrows and blocks). This model will show how a user is expected to work with the application in order to solve its main task.
In order the present the application first show them the requirement list and talk about them, then the high level architecture and finally the application workflow process diagram which can be followed by a live demo.
The most important rule is to present at a fairly high level with lots of diagrams and models to show what you are talking about.
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 looking for advice on how to give a junior developer a chance to gain experience on a big project with tight deadlines without hurting the timeline. If we all know it will take a little longer with the developer because of less experience, then what is the best way to give them a portion of the project and spread the risk? Giving these developers the ability to learn on the job on real projects instead of handing down maintenance work all the time is important to me, and I want to find a way to make it work.
You need to know if they grasp the problem you are handing down. When I have to do this here is my approach:
Give them a piece I think is a stretch for them but doable.
Explain the importance of the piece, how it fits into the larger picture, and how they will contribute to the project success.
Ask them to go away, take some time to think about it and then write up several possible solutions with pros and cons of each. This shows me if they have grasped the problem and if they can design a solution.
If they come up with something that looks reasonable, then let them at it. If not, we meet and discuss the problem some more and I give them another shot.
Giving them a chance to design the solution gives them ownership and lets them prove themselves. Having them communicate the design to you first with pros and cons gives you the confidence that they can complete the solution on time.
If they can not think of any possible solutions and possible outcomes of each solution then they are not ready to step up to this problem. They will need closer mentoring and smaller problems which have been designed by another more skilled developer first.
Very short, clear goals that are measured and checked on very often.
Bite size approach will help the junior realize that big things are accomplished by doing the very small things, very well, over and over and over...
Also, consider doing the conceptual design, or a feature spec, or even the tech spec to get their feet wet and let them have more and more say if they take to it like fish to water.
Although this wont work in all shops, pair programming is a great way to get juniors on board quick. However pair them with some of your more sociable developers for best results.
This way they get mentored, are doing important work, and learning important things related to your work-style, and the more sociable devs in your shop will probably enjoy mentoring juniors anyways.
How well do you know the junior? Certainly there must be something he/she has shown an interest or special aptitude in. Try finding pieces of the project that are digestible and fit the profile.
Assigning a mentor and making sure design and code reviews are a part of the process are important, especially if the junior is not well known.
If the junior is new to the subject matter, technology, or team, it may be advantageous to also make sure the piece he/she gets to work on is one of the better documented pieces (decent requirements definition, and possibly even a tech design already prepared by a senior). I have been able to do this in the past. I had a reasonably well fleshed out technical design of a medium-sized task, parceled out parts of it to a new team member, then also did code reviews and corrected the work. Even with the time spent doing the review and correction, it was a great way to get the new dev involved and use their ability to help finish the tasks. The new dev learned a lot along the way too.