Computer Programming High-level Snippets

Computer programming (or coding) is a very broad topic, but fortunately the “high-level” information can be found in hundreds of thousands of places from the Internet. I have created a compilation on coding (or computer programming) related topics from multiple online sources which I am:

  • Giving credits to the original writers/bloggers by linking to the web pages.
  • Including part of their writings in this blog post as snippets.

Best Software Engineering Books

Noop.nl has this best software engineering books ever (the top 10):

  • 1. Code Complete: A Practical Handbook of Software Construction – Steve McConnell
  • 2. Head First Design Patterns – Elisabeth Freeman
  • 3. Rapid Development – Steve McConnell
  • 4. Design Patterns: Elements of Reusable Object-Oriented Software – Erich Gamma
  • 5. Applied Cryptography: Protocols, Algorithms, and Source Code (2nd Edition) – Bruce Schneier
  • 6. Agile Software Development: Principles, Patterns and Practices – Robert C. Martin
  • 7. Joel on Software – Joel Spolsky
  • 8. Peopleware: Productive Projects and Teams (2nd Edition) – Tom DeMarco and Timothy Lister
  • 9. The Mythical Man-Month, Anniversary Edition (2nd Edition) – Frederick P. Brooks
  • 10. Refactoring: Improving the Design of Existing Code – Martin Fowler

Popular Programming Languages for Software Engineers

Tiobe Index reveals/updates a list of the most popular programming languages for programmers / software engineers as well as this answer to the question “What programming languages should a modern day programmer have in his/her arsenal?” by Joshua Levy on Quora.

  • C for general familiarity with systems programming, and understanding how compilers, memory management, and the stack work.
  • C++ because any programmer who works with C should also, as a practical matter, know C++, and the values and drawbacks of its features relative to C. Performance-sensitive or large-scale data processing (such as code at Google, Facebook, or most other serious tech companies) is still often best written in (a subset of) C++. It also teaches some useful facts about messy topics like code generation (templates) and multiple inheritance.
  • Python or Ruby for familiarity with mainstream, modern scripting languages. Dynamic typing, metaprogramming, rapid prototyping, and Web-oriented development are all easily learned with either of these languages. (Avoid debates on which is better. They are both good to know, and more similar than they are different.)
  • JavaScript because you can’t be a well-rounded developer without knowing basic Web development. It’s an interesting language in itself, albeit with numerous flaws, and not all that different from Python or Ruby. It can also be used server side.
  • Java or C# for mainstream, modern, imperative, garbage-collected languages. Development in a higher-level, more modern language like these is not just popular, but stylistically different enough from C++ that you probably shouldn’t avoid learning it. Java especially can introduce you to heavyweight, enterprise-style development (for better and for worse). They acquaint you with extensive sets of libraries that are good to know about, so you don’t waste time building things that already exist.
  • Bash, at least at a basic level. This includes use of common Unix/Linux command-line tools like ls, grep, and sort. This is needed to be proficient in general problem-solving, debugging, and quick data processing on any Linux system. Without this, you may find yourself taking hours or more on something a hacker familiar with Bash could do in minutes.
  • At least one or two other languages of a different family. It doesn’t matter if they are popular or esoteric, but you should have familiarity with functional languages (Lisp, Scheme, Clojure, etc.) and with type inference (ML, OCaml, Haskell, Scala), and ideally with more specialized languages (Prolog, Erlang, XSLT, etc.). Mathematical and statistical tools like Mathematica, Matlab, R, or Maple are also good. Some might say this isn’t important since industry doesn’t use these languages broadly, but it improves your understanding of programming enough that it can make a big difference in the long run.

You should also know one or two of the languages above at a deeper level. This would mean you have read and written a large amount of code in that language, know its subtleties, and have worked with or read the code of people who have expert-level proficiency in it. This also means knowing something of how the language internals work — at least look at code for the language’s compilers or interpreters, for its built-in libraries, and (if applicable) its native bytecode or assembly output.

Also, athough these are not usually called programming languages, a good programmer should also know database/query languages, formatting languages, and data formats. Minimally: SQL, HTML, CSS, XML, XPath, and regular expressions.

A couple other languages are important but less essential:

  • PHP is the most popular server-side Web development language. However, it’s not in the essential list above, simply because it’s not a good first language due to its poor design and shortcomings, and because once you know Python or Ruby, it is not too difficult to pick up.
  • Perl has a venerable history and in some cases is still the quickest tool for a job. It’s also fast. However, it is a poor choice in most situations due to its age and poor readability and maintainability.

Solid experience in all of this takes a while, but it’s one of those situations where being ahead keeps you ahead. Once you have breadth and depth, you’ll be stronger and more flexible than most professional programmers, which will help you find better and more challenging programming jobs, which will allow you to learn from the work and from others and keep improving your skills quickly.

Python vs Ruby

What are the advantages of Python over Ruby? Robert Cezar Matei’s answer on Quora:

  • The two are more similar than they are different, in everything from design to disadvantages to common uses – you can’t really go wrong either way, and shouldn’t base your decision on syntactical differences.
  • As a Rubyist, Python’s main advantage has nothing to do with the languages’ features. It’s more subjective: it seems to me that Python has more momentum amongst serious computer scientists. It’s increasingly popular in academic and scientific applications, and a lot of the technologists I respect the most seem to prefer it. By comparison, the Ruby community feels more designer-y and relatively more novice.
  • What this means is that while the Ruby world has very slick out-of-the-box product solutions, the Python world seems to produce more exceptionally well-written components like Tornado (web framework). Combined with it being used at Google and the potential for stuff like LiveNode to be released as open-source, I’d cast my lot with Python if I were starting today.

What are the advantages of Ruby over Python? Jonathan Ragan-Kelley’s answer on Quora:

  • Broadly, Ruby and Python implement very similar models, and have similarly powerful libraries and communities. The biggest distinction is in syntax.
  • Ruby includes several syntactic features which make dynamic extension of and higher-order interaction with external (library) code more straightforward.
  • Blocks allow arbitrary, multi-line closures to be cleanly passed in-line nearly anywhere. (Closures are anonymous functions which are lexically scoped inside the point at which they are defined, so they can access enclosing stack variables.) Python allows two syntaxes for in-line closure declaration: lambdas and nested def statements. Lambdas are equivalent to Ruby blocks, in that they are expressions which evaluate to a closure (and so can be used in-line), but syntactically they can only easy express a single expression, not multiple nested statements. Nested definitions have the full syntax of any other function definitions, and so easily support multiple statements and control flow within themselves, but they are statements not expressions, so they cannot be used in-line.
  • Mix-ins allow imported classes and modules to be extended and overridden by user code after it is imported. Python’s runtime model is sufficiently dynamic to inject new or altered methods and fields into an external class or object, but its syntax is procedural (assigning values to fields of an object), rather than declarative and identical to the standard class definition syntax.

Python vs PHP

Why is Python better than PHP? Owen Yamauchi’s answer on Quora considers both technical reasons and cultural reasons.

Technical reasons:

  • Python has a real module system.
  • Python distinguishes indexed arrays from associative arrays.
  • Python is stricter about dumb error conditions; e.g. undefined variables.
  • Python’s philosophy is more general-purpose than PHP’s originally was and thus it does not have weird artifacts like magic global variables $_GET and $_POST.
  • Python has functional-like features that are distinctive among mostly-imperative scripting languages, like list comprehensions. PHP has no such things.
  • Python has fewer easily abusable ways to write shitty code like extract().
  • Python does not exhibit as many head-scratchingly strange behavioral oddities as PHP, for example the fact that in PHP, you cannot use the array-index operator on a function call expression.
  • Python generally has a nicer standard library.
  • Python ships with a REPL, which includes an interactive documentation viewer. Facebook had to write their own for PHP.
  • Python has passable Unicode support. PHP (5.2 anyway) is no better than C in this regard.

Cultural reasons:

  • Python was not developed by a man who has publicly stated that he does not enjoy programming, and who clearly does not understand how to properly design a programming language.
  • Python does not suffer from the “hobbyist” problem to the same extent that PHP does. This is the problem wherein someone with no real training in programming works through a PHP tutorial on the Internet (many of which were written by hobbyists who do not really understand programming) and then thinks they understand programming.
  • On the flip side of this, Python is generally more popular in the open-source community, so there are more cool open-source Python projects than PHP.

Why would someone choose PHP over Python? Allen Cheung’s answer on Quora:

  • More familiarity/comfort with C/C++ syntax
  • Rapid prototyping, knowing the code probably won’t survive for long
  • Writing against an API that has a mature PHP API and an immature Python one (e.g. the Facebook developer API in its early days)
  • Choice of multiple mature web frameworks

Java, Shortcomings

Why do some people hate Java? Sergei Turin’s answer on Quora:

  • Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function. — John Carmack
  • Back when I was starting out in computer science I thought by today we’d be writing a few lines of code to accomplish much. Instead, we write hundreds of thousands of lines of code to accomplish little. — Lispian
  • Such is modern computing: everything simple is made too complicated because it’s easy to fiddle with; everything complicated stays complicated because it’s hard to fix. — Rob Pike
  • Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly. — Steve Yegge
  • Languages that try to disallow idiocy become themselves idiotic. — Rob Pike
  • The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong
  • So much complexity in software comes from trying to make one thing do two things. — Ryan Singer
  • The purpose of software engineering is to control complexity, not to create it. — Dr. Pamela Zave
  • “Design patterns” are concepts used by people who can’t learn by any method except memorization, so in place of actual programming ability, they memorize “patterns” and throw each one in sequence at a problem until it works. — Jason Garrett-Glaser (aka Dark_Shikari)
  • Under the doubtful disguise of the holy “code reuse” an insane amount of gratuitous complexity is added to our environment, which makes necessary industrial quantities of syntactical sugar to make the ensuing mess minimally manageable. — Uriel
  • It is not that uncommon for the cost of an abstraction to outweigh the benefit it delivers. — John Carmack
  • The beauty of small and simple code is that you can bend or break the rules as long it stays small and simple. Rules allow people to write code without thinking. [And when] you dont think [...] you get bloated code that just concatenates stupid patterns. People stop thinking and questioning [and] then its just worshipping some rules without any pruporse. — Cinap Lenrek
  • The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. — Paul Graham
  • We ignore the real problems and instead invent problems for which we know how to solve–and create a spaghetti tangled mess instead, thinking that our ‘invented’ problem is more interesting. We then even go on to congratulate ourselves for solving the “fake” problem, leaving the real problem alone. — William Woody
  • The notion of OOP was that you could leverage other people’s code and get those advantages. But that’s not the case. Instead you find code that “almost” does what you want, and then tweak and adjust it. And most of the time, it’d have been faster to simply rewrite it — and the code base would have been smaller. — Lispian

C Programming Language – Building Blocks

What programming language has the maximum credibility today? Kevin Ernest Long’s answer on Quora:

  • It’s still C. Assuming you mean the credibility of the language and not the credibility its use might confer upon the user.
  • If I told you I was going to write the most efficient web server ever or a faster 3d shader algorithm and I was going to write in the “X” programming language. The most credible programming language would be C. This of course will vary based on your goals and constraints.
  • My answer assumes that you are looking to solve hard problems rather than common problems.
  • C is the most general purpose of all computer languages and is commonly used to create the operating systems and core system libraries that are the building blocks that more specialized languages, niche languages and DSLs (Domain Specific Languages) rely upon.
  • If the task is unknown and the constraints unknown then C has the most credibility when it comes to the odds of success.
  • Even more often than other languages; programming in C is a lot like creating your own mini-language to solve the problem at hand. I’ve programmed in over thirty languages and dialects most of which are derived from C in some way.
  • I mostly program in languages and against libraries that are more specific to my problem domain (these days Python and JavaScript) as these are a more efficient way to solve the common problems most of us face.

Google’s C++ Crawler

Why did Google move from Python to C++ for use in its crawler? Benjy Weinberger and Eisar Lipkovitz both have answers on Quora:

Software Engineer at Foursquare, formerly at Twitter and Google, Benjy Weinberger:

  • Google has very robust, state-of-the art C++ libraries that handle a great many of the concerns of large-scale distributed systems: networking, monitoring, logging and so on.
  • The best-maintained versions of the client libraries for the internal systems the crawler interacts with are in C++.
  • Even small performance gains add up to a lot of money when you multiply them by many thousands of machines.
  • Google does not optimize for speed of development. Code is written once, read many times and run many, many, many times. The time it takes to write code is rarely the limiting factor.

Engineering VP at Google, Eisar Lipkovitz:

  • Crawling is relatively small part of the “building an index” process.
  • Python was “abandoned” from the core search stack around 2000.
  • Crawling main bottleneck is concurrency. We crawl MANY pages per second and each one of them might take minutes to successfully crawl [they are server bound]. It’s entirely possible modern Python allows for massive parallelism per machine/process, but certainly wasn’t the case a decade ago.
  • HTTP and other related protocols didn’t change much in over a decade so the lower level crawling code doesn’t benefit from the supposed faster development cycle of Python.

No Better Programming Language to Replace C++

Why hasn’t a fast, practical, and reasonable language supplanted C++? Joshua Levy’s answer on Quora:

  • Massive investment is required. Bringing a new programming language into widespread use requires a large amount of effort and time. Usually about a decade, typically with the support of either a large company or community. This must include the design and development of the language, the development of (or integration with) standard libraries, the building of a solid compiler/interpreter, and — last but not least — the community development needed to popularize the language. Look at the languages in widespread use now — C, C++, Java, Python, Ruby, PHP, C#, JavaScript, Perl — and this is quite clear.
  • Language superiority rarely drives adoption. Again, look historically. Lisp had garbage collection and the dynamic capabilities now appreciated in Ruby or Python, with better performance, yet failed to maintain traction. Hardly anyone thinks PHP is a well designed language, yet it’s still going strong (with the support of giants like Facebook), even when similar alternatives like Python or Ruby are by most assessments preferable. In fact, when it comes to adoption, practically every big factor is more important than the fundamental design of a language, including backing by businesses or communities (Sun, Microsoft, the Python community), tools (Eclipse, Visual Studio), library support (C++, PHP, Java, etc.), killer apps (Rails), platform (Mac/iPhone, .NET), and historic niche expertise (physicists with Fortran).
  • Lack of expertise. Surprisingly, considering the number of people making their living programming, broad knowledge of programming languages is remarkably rare. Most developers know at most two or three of them well, and often they are from the same family (C++ and Java, for example). Partly this is due to the large investment needed to learn languages, and partly it is cultural insularism. (As an illustration, see how many Java programmers you can find who use REPL-style exploratory development, such as with BeanShell, Rhino, or whatever.) It’s harder to promote the importance of first-class functions, type inference, closures, metaprogramming, continuations, or around methods, for example, when they are unfamiliar concepts. Even worse, the designers of successful programming languages themselves often seem not to have seriously surveyed other languages for ideas. (There are of course exceptions here.) The consequence is, features that seem “reasonable” in retrospect were ignored at the time they could have been added.
  • Difficulty of design. Even if you have brilliant and informed designers with plenty of support, it’s still hard to make good choices when designing a language, because it takes so long to learn your mistakes, both of omission and commission. Fundamentally, language design is a case where tiny details compound to have giant effects. It’s hard to predict what a half million-line codebase in a new language will look like, and what the problems will be. And by the time you know, it’s usually too late to change anything substantial.
  • Difficulty of implementation. Writing a good compiler or interpreter and platform is hard. And without a full-featured and solid platform, the language will go nowhere. It’s easy to start, and run a few toy programs, but the expertise required to build, say, an optimizing compiler that competes with gcc on optimization, or a virtual machine that competes with Sun’s JVM, is immense. And it needs to be built solid enough, or at least have enough support, that people will trust it enough to use it.
  • Rapid software business cycle. In the software industry, perhaps because it is so volatile, businesses often avoid long-term investments of this sort. Although there are almost certainly massive productivity gains to be had by improving the state of programming languages, the investment is on such a long scale relative to other factors (such as evolving use of the Web, or mobile technologies, or consumer products) that such investments usually seem expensive and risky.

It’s all too easy to forget just how large these barriers are when excited by a new programming language (or frustrated with the obvious shortcomings of an old one). Really, unlike many situations in software engineering or programming, where quick hacks can have big payoff, getting widespread adoption of a new langauge may be more akin to building a large company, with the same challenges of having a good solution, a strong organizational leader, an angle for breaking into the market and then maintaining and growing user base, and so on.

.Net Programmers

Why we don’t hire .NET programmers from Expensify Blog explains why .Net programming don’t fit with tech start-ups:

  • If you ever want to work in a startup, avoid .NET. It does you no favors. If you are a start-up looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.
  • Yes, .NET developers are great at what they do. It’s the most modern platform for application development on the planet. Microsoft has always produced the best tools for building internal business applications, and .NET is their masterpiece. There’s a reason why they own that space; they earned it. That space employs millions of people, and those people are unquestionably the masters at what they do.
  • But what they do is very, very rarely start-ups. I’m sorry if that sounds offensive, but that’s a simple fact. You can measure this yourself: go to any list of startups, maybe look at YCombinator’s recent graduate class, or Scoble’s list of picks for 2010, or Sequoia’s list of seed companies – or go find a list you like better. Do a curl (or your .NET equivalent) on each domain, and see how many are running a Windows server: I think you’ll find the fraction very small. Don’t get me wrong: there are a lot of people who aren’t interested in working at a startup, for a lot of very valid reasons. But if you are the odd person who is interested, it’s worth asking: why do so few use .NET?
  • Because .NET is designed to extend, not disrupt. The same could largely be said about J2EE, but in general anybody who “grows up” with these self-contained, highly-automated platforms can’t help but view computers in a different way than those who start from a lower, less automated, more difficult level. As one of the coherent commentators says below, Joel Spolsky himself laments schools teaching Java with the same basic reasoning of my article above, albeit more diplomatically stated. .NET is designed to tightly integrate with and seamlessly extend the Microsoft stack in extremely powerful but ultimately incremental ways. Again, there’s nothing wrong about that if that’s what you want to do. But if that’s not what you want to do, then .NET probably isn’t the right choice, as evidenced by how few people in the startup world choose it.

Getting into Programming

Software engineers / programmers all have stories on how they got into programming in the first place.

Jean Hsu’s “It’s not too late to learn how to code”:

  • It is difficult! Things that take awhile at first will come naturally to you later on. Of course some people are more naturally disposed toward the type of logical thinking that programming demands, but I believe that in the majority of cases, people assume they aren’t cut out for it before giving it a fair shot. Though of course, having people believe that programming is “too difficult” and that the average person is “not smart enough” strokes our egos and makes us feel like we’re part of some super-elite hyper-intelligent group.
  • Mentally prepare yourself for roadblocks. I used to think I was cursed, because every time I tried to setup something new (new development environment, tool, library, etc), something would always go wrong. It took many years for me to realize that with all the different combinations of user operating systems, software versions, etc, the documentation was often outdated or not comprehensive.
  • Do you like it? Forget about if you think it’s too hard; do you think it’s fun? When you struggle for hours debugging something, and finally, it runs as expected, do you feel a rush of excitement? Do you look forward to having a few hours to figure something out? Those are the things that attracted to me to software–I just didn’t worry too much about if I could make it or not.

Matt DeBoard’s “How I became a programmer”:

  • How did you learn Django in 11 weeks? I want to make it clear that I didn’t set out to learn Django per se. Django is just a very nice toolkit of abstractions that makes creating web applications easy using Python. As far as I’m concerned learning Django was incidental to learning to program. I did not – and still don’t – want to be considered a “Django developer.” I’m not even sure I want to refer to myself as “a Python programmer.”
  • In other words, I do not feel that I would be as modestly competent as I am today if I had spent an inordinate time becoming an expert at the abstraction layer of Django, instead of learning the concepts that make Django work.
  • How did you show the company your skills? Did you show them the projects you’ve made? Github, Github, Github. I can’t emphasize it enough. Make stuff, put it on github, show people you’re passionate and smart and curious.
  • If I had to summarize the big overview of how I did what I did, I’d say: Ask questions, be curious, be passionate.
    Learn a language, not a web framework for god’s sake. Work hard. Network, attend meetups, tweet, blog, be social and show people you’d be fun to work with, and a credit to team. (Optional) Put yourself in a position of desperation, so there is no choice but to succeed.

Older Software Engineers/Developers

Lessons of Failure’s Five Pervasive Myths About Older Software Developers shows why older software engineers are invaluable for a tech company:

  • Yes, older software developers have higher salaries than younger ones. But what exactly are you paying for here? With an experienced software developer, you’re paying for all the experience that comes with past project successes and failures. Those are expensive lessons if you want to pay for them directly during your tenure as a manager. But if you buy into an experienced worker, that’s like getting insurance against some of those classic mistakes in project management and software development that you don’t have to repeat. Meaning you look better on your annual review because you hired smart people that know how to get the job done.
  • It’s actually because of their past experience, that more experienced software developers can migrate to new technologies, frameworks, and systems more quickly and in greater depth. For example, if you learn a GUI framework in C/C++, you have a mental model about message passing, event handling, MVC patterns used to design the system and separate presentation from back-end logic. The very first time you learn a GUI framework, in addition to the syntax, the examples, and the quirks of the library, you also need to learn all the conceptual stuff. And after two, three or more GUI frameworks, you notice that they all have very deep similarities outside of the syntax. You might even notice newer frameworks have overcome substantial limitations that you used to have to work around with complicated hacks. Those insights are lost on someone new to the framework. And those insights can really boost productivity in ways you’re not able to directly measure.
  • I think it would be fair to state that experienced software developers are less willing to work those long, painful hours because they’ve learned the hard way that there are productive limits to pushing yourself 80 hours a week for months on end. It’s called burnout, and I’m willing to bet that anyone who has already experienced it in the past simply isn’t as eager to go there again. But with that said, the supposed reason of “family commitments” is bogus. High-quality, experienced software engineers are ruthless time managers, and those with families are even more motivated to get things done in allotted times. They may have dance recitals and soccer games to attend to, but they also make up that time in off hours and highly focused work during the 40 hours they’re given in a week. Good software engineers with families must become highly efficient with personal time management or they quickly get buried with the deluge of work coming their way.
  • Lost mental agility is a poor excuse to not hire an older software engineer in light of the fact they’ve seen, done, and lived many more successes and failures than a younger developer. Experienced developers have tons of past projects to draw from and assist in avoiding bad decisions today. Younger developers have new ideas which are important, but often untested and unproven. Having both perspectives on your team is of great value.
  • Anyone who believes this is probably someone who doesn’t like their ideas criticized by those who’ve been around long enough to see really stupid decisions put into practice again and again. Experienced software developers smell crap a mile away. They don’t buy your stories about how the product isn’t well received in the marketplace because they’ve been interacting with the customers for years and know you’re trying to cover up a future layoff in the company. They won’t put up with managers asking them to work 80 hours a week because the customer wants the software next month and they already told you it will take 3 more months to complete with the features agreed upon.

Non-Technical Founders for Tech Start-ups

YCombinator.com’s advice for founders of tech start-ups who initially had no technical / coding experience at all:

  • If you have a startup idea and you don’t know how to code, learning how to code enough to implement the idea all on your own is probably not cost-effective from a time standpoint and you’re more likely to end up with a mess of non-functioning code than anything else.
  • That being said, at least to me, knowing even a layman’s amount about programming will gain major points with the potential technical co-founders you do meet.
  • I get approached by friends/acquaintances on a weekly basis with some startup idea. And I mostly think, “So basically you’re suggesting I spend 10 hours a week of my free time for six months to build Facebook For Cats, while you make some half-assed attempt to do some marketing or whatever, and if there are any technical issues I can’t even discuss them with you because it’ll go over your head, and if there are any tedious technical issues you can’t even help with those.” It’s pretty much a non-starter right there.
  • But knowing even a little bit about programming could go a long way. It means your idea is probably a little bit better than “Facebook For Cats,” because maybe in programming you learned about some company’s API and how to leverage it. It means I can split up work and give you some of the easier programming tasks and feel like we’re putting in close to the same effort. And it means I can tell you things like, “the service doesn’t always return well-formed XML so we should find a validator and then run it on the response before we insert it into the database,” and you’ll know what I’m talking about.
  • It all starts with the product, and the product usually means code, and having one and a half heads coding will usually be more productive than just one. Learn enough to be that half a head and you’ll go far.

Comments

Leave your comments

  • Your first comment will be reviewed before getting posted.
  • Your subsequent comments will be posted without review.
  • All spammy comments will be deleted.