calc1 and calc2 are really bad names. Names should always clearly describe what they are for or do. calculateCircleCircumference and calculateCircleArea would be better
choices.
I'm not a big fan of the names commaToDot and commaToDot either. I'd prefer more conceptional names such as parseNumber and formatNumber, maybe even parseGermanNumber and formatGermanNumber.
A slightly better HTML structure would be in order: Each calculator could be surrounded by a <form> element and there is an <output> element specifically for display calculation results.
In current JavaScript one should prefer const and let over var.
The following suggestions may introduce concepts, that the students haven't learnt yet, but they are considered good conventions.
For a better separation of layout and logic it is usually suggested not to use on... event handler attributes, but instead assign them using addEventListener.
Also one should move all element look ups to the initialization. This could look like this (notice the changed IDs):
const circleCircumferenceRadiusInput = document.getElementById("circle-circumference-radius-input");
const circleCircumferenceOutput = document.getElementById('circle-circumference-output');

function calculateCircleCircumference() {
    // Using separate variables so "const" can be used.
    const inputString = circleCircumferenceRadiusInput.value;
    const input = commaToDot(inputString);
    if (isNaN(input)) {
      circleCircumferenceOutput.innerHTML = "Please enter a number!";
    } else {
      const output = 2 * Math.PI * input;
      circleCircumferenceOutput.innerHTML = dotToComma(output);
    }
}

document.getElementById('circle-circumference-button').addEventHandler("click", calculateCircleCircumference);

This can be simplified a bit by wrapping HTML of the calculator in an <form> element and referring to the needed elements by name. Also I'm wrapping the code in an initialization function to avoid lots of global variables. Both of these prepare for generalizing and reusing the code.
<form id="circle-circumference">

Calculate circumference of circle

    Radius of circle: <input type="text" name="radius"> <button name="execute">Calculate</button>

    Circumference of circle: <output name="output"></output>

</form>

function initCircleCircumferenceCalculator(form) {
  const radiusInput = form.elements["radius"];
  const outputElement = form.elements["output"];

  function calculate() {
    const inputString = radiusInput.value;
    const input = commaToDot(inputString);
    if (isNaN(input)) {
      outputElement.innerHTML = "Please enter a number!";
    } else {
      const output = 2 * Math.PI * input;
      outputElement.innerHTML = dotToComma(output);
    }
  }

  form.elements["execute"].addEventHandler("click", calculate);
}

initCircleCircumferenceCalculator(document.getElementById("circle-circumference"));

Now that we have the initialization function it's easier to generalize this so that it can be used for multiple calculators:
function initCalculator(form, inputName, calculationFunction) {
  const inputElement = form.elements[inputName];
  const outputElement = form.elements["output"];

  function calculate() {
    const inputString = inputElement.value;
    const input = commaToDot(inputString);
    if (isNaN(input)) {
      outputElement.innerHTML = "Please enter a number!";
    } else {
      const output = calculationFunction(input);
      outputElement.innerHTML = dotToComma(output);
    }
  }

  form.elements["execute"].addEventHandler("click", calculate);
}

// Circle circumference
initCalculator(document.getElementById("circle-circumference"), "radius", r => 2 * Math.PI * r);

// Circle area
initCalculator(document.getElementById("circle-area"), "radius", r => Math.PI * Math.pow(r, 2));

The next step could be modify initCalculator so that it supports multiple input fields.


No. The matching for a-zA-Z would be slower than the exact character-set you supply: RNBQKrnbqk.

You can observe this behaviour by checking the backtrace it generates. I compared 3 different patterns, two being your own, and the third I found on chess.stackexchange.com:

(\d?)[a-z](?=(\d?)(.*))(?=(.* ){5})

has 64 matches generated in 14323 steps

(\d?)[rnbqk](?=(\d?)(.*))(?=(.* ){5})

has 32 matches generated in 7512 steps

and the pattern from chess.stackexchange:

([rnbqkp1-8]+\/){7}([rnbqkp1-8]+)\s[bw]\s(-|K?Q?k?q?)\s(-|[a-h][36])

has 2 matches generated in 95 steps

Note that I have enabled the ignorecase flag in all three of them.


Welcome to Code Review!
Shellcheck
Use the amazing shellcheck utility to verify for common practices when writing bash/shell scripts. It reports missing shebang.
Loop using seq
Since you know the lower and upper bounds, and those are pure integers, use the seq command to iterate through them. You won't need to do custom increments and variable swaps.
Inner loop
Begin your inner loop with a value starting from current outer loop value + 1.
Variable
Using more descriptive variable names helps in understanding your code.
Parallelization
To achieve faster results, you can maybe use parallel to do the diff comparison for different files. If the set of files are small, you can also run the obabel tool in background, or disown the command from script entirely (depending on your requirements).

#!/bin/bash

LOWER_BOUND=0
UPPER_BOUND=2

for i in $(seq "$LOWER_BOUND" "$UPPER_BOUND")
do
    ((INNER_START=i+1))
    for j in $(seq "$INNER_START" "$UPPER_BOUND")
    do
        obabel "filename${i}.xyz" -oconfabreport -xf "filename${j}.xyz" -xr 0.2 > "Results.${i}.${j}"
    done
done

I'll leave parallelization to your own implementation. You can refer this excellent demonstration of parallel command.


The code you have works, and is very nicely-formatted.

There are only two things I would change, stylistically speaking:

Explicitly pass input parameters by value. This should have been the default, but it wasn't in classic COM-based VB, so you need to write it out. ByRef is actually a perverse choice for the default, since it is almost never what you want. It is certainly not what you want for primitive types like Long. (But it probably is what you want for strings, unless passing them out-of-process, e.g. in a COM server.)
As others have pointed out, l is a rather poor choice for a parameter name. Roland says one problem with it is that it can be difficult to distinguish from the digit 1 or a capital I. I'd say that's more a reflection on your choice of a font for your editor, but this is still a valid concern. My major issue with it is that it looks like a lame attempt at Systems Hungarian notation. I know this used to be all the rage in VB programming, but that was mostly cargo-cult. Unless you're using variants (and you probably shouldn't be) the language is sufficiently strongly-typed that embedding type information in the name of the variable serves little point. The only type prefixes I allow myself are for names of controls (mostly because it makes finding them in IntelliSense significantly easier; I always remember the type of control much more readily than I remember its name) and "member" prefixes (e.g., m_). Aside from that, the only prefixes you should be using are meaningful semantic ones, in the Apps Hungarian vein.

Therefore, I would rewrite your function's prototype to look like the following:

Function RgbToHex(ByVal color As Long) As String

Otherwise, the primary issue with your code is that it is slow!

Why? Well, there are a couple of reasons:

String operations are extremely slow in VB since they all require multiple BSTR allocations and deallocations, not to mention the fact that the calls to the string-manipulation functions themselves cannot be inlined.

Now, I notice that you did correctly force the use of the string-based Right function by using the $ type suffix, which is a standard trick to ensure as optimal code as possible. This is good. You didn't do the same thing for Hex. Personally, I have no idea whether it is actually necessary or not—is there a variant-based version of Hex? Maybe, I don't know. And I don't want to have to worry about it when I write or review code, so I always use the $ type suffix when I am working with strings. I suggest that you do the same. (Mat's Mug says Hex does have a variant version, so looks like this is sage advice after all!)

But the major problem here is that you're calling six different string-manipulation functions, plus concatenating those three intermediate strings. Slooooow! To optimize the code, it will be critical that we find a way to keep these calls to a minimum.
You are using floating-point operations in your byte-extraction code.

In your defense, constant expressions like 2 ^ 8 should be computed by the compiler at compile-time, so that your code never actually has to do an exponentiation operation. I would have made exactly that same assumption. Unfortunately, the VB 6 compiler (even with all optimizations enabled) is not that smart. These two exponentiation operations are done at run-time, with a call to the vbaPower function exported by the run-time library. Personally, I'd say this is a bug in the compiler, but it's not going to get fixed now, and you have no choice but to work around it.

The other bad news is, once you've got a floating-point value, the entire arithmetic operation has to be done in floating-point mode. So for each of your bit-extraction operations, the compiler is going to emit code that converts an integer value into a floating-point value, loads floating-point constants, performs an exponentiation operation, fixes up the result, and then does a division.

While it is true that floating-point operations are no longer as slow on modern machines as they used to be, generally obsoleting the classic optimization advice to avoid floating-point operations whenever possible, VB 6 is not sufficiently modern for that advice to hold. :-) There is no way to get the VB 6 compiler to emit SSE instructions, so you're stuck with the legacy x87 FPU, and that means that you're stuck with a bottleneck intrinsic in its design, arising from the inability to move values directly from the floating-point stack into integer registers and vice versa. The compiler emits code to handle all of this for you seamlessly, but it's still slow. So, at least in the context of VB 6, it's still valid optimization wisdom not to inter-mix floating-point and integer operations.

In this case, though, you don't need floating-point operations at all! You could have done everything in integer mode, just by explicitly using an integer division:

r = (l And ColorConstants.vbRed)
g = (l And ColorConstants.vbGreen) \ (2 ^ 8)
b = (l And ColorConstants.vbBlue)  \ (2 ^ 16)

Then, the constants even get folded correctly, with the exponentiation being done at compile-time.

As originally written, your function compiles to hundreds of lines of machine code. I made an optimized build and then disassembled it, revealing a total of over 1,000 bytes of machine code just for that one function. It contains tons of embedded function calls (slow), string allocations/deallocations (slow), and extremely sub-optimal code to store, compare, and manipulate floating-point values (slow).

Let's have a go at optimizing it.

Comintern made one attempt already, and it is interesting to study. Immediately one problem jumps out—it does not produce correct results. Specifically, the order of the red and blue component values are reversed, such that instead of AABBCC, his code gives CCBBAA. On little-endian architectures, like the x86, integer values are stored in memory with the least-significant byte at the smallest address. This means that "RGB" colors are actually represented in memory using an BBGGRR format, whereas you are wanting the standard, web-style RRGGBB format for your hexadecimal output. This is a minor bug, though, and should be fixable.

My real issue with his code is that it makes a series of function calls, specifically to the RtlMoveMemory API function, which he has aliased to CopyMemory. I've seen this technique before for optimizing code in VB 6, and while it has power, it's not a panacea. Why? Function calls are expensive, too! Memory copying is a relatively cheap operation, O(n) at the worst, and has a small constant multiplier assuming an optimal implementation (which RtlMoveMemory does provide), but the context switching required for a function call introduces a lot of overhead that it would be nice to avoid. This is especially important in a very small, do-one-simple-thing function like you have here. VB 6's compiler does a very poor job of inlining code, so the execution cost of this function would be dwarfed by the overhead cost of making these system calls.

To be fair, Comintern's code is still going to be significantly faster than your original attempt, but we can do even better.

How? By using bit-manipulation tricks to do the byte-swapping. Basically, you do what you would have done in C (or at least, what I would have done in C, maybe you're a real VB programmer and don't think in the language of blasphemy). This is basically what Roland Illig did in his code. You start with the input value, in AABBGGRR format. Then, you isolate each of the individual color components (except the alpha channel, which we don't care about):

The red component is trivial: you just mask off all but the bottom-most byte. Bitwise masking is done with a bitwise And operation.
For the green component, you first divide by &H100 (which is the same as a right-shift by 8, except that you can't do a right-shift in VB). That throws away the bottom-most byte, shifting everything down by one byte. Then you can simply mask off all but the bottom-most byte, which is the one that used to be the middle byte.
The same thing is true for the red component, except that we divide by a larger constant, &H10000, to achieve what is effectively a right-shift by 16.

My hope/expectation was that the VB 6 compiler would actually optimize these division operations to right-shift operations, since that will be faster—and indeed, that is exactly what it did! Notice that it is critical that we use the integer-multiply operator, \, here.

The next step is to take those isolated byte values, and pack them together in the proper order. Again, Roland's code does the same thing I would have done: uses a multiplication in lieu of a left-shift operator. Unfortunately, VB 6's compiler can't/won't optimize this multiplication into a left-shift. Fortunately, multiplications are not slow on modern processors, so this is not a big loss.

Finally, we want to make a single call each string-formatting function to pretty-print the final output. Roland's idea was to multiply the integer value by &H1000000 to ensure that it is properly zero-padded—very clever! I did it a bit differently: I decided to check and see if padding is actually necessary, and if not, skipping the call to Right altogether!

Public Function RgbToHex(ByVal color As Long) As String
    ' On little-endian architectures, "RGB" color values are actually stored in memory
    ' in an AABBGGRR format. However, web-style hex colors are always formatted in an
    ' AARRGGBB format. Neither Windows nor HTML care about the alpha-channel value
    ' (always the upper, most-significant bit), so we are going to simply ignore it.
    ' Otherwise, we have to do some bit-twiddling to swap the red and blue color channels.

    ' Extract the individual red, green, and blue color channels.
    ' (Although they are only bytes, continue to store these intermediate values
    ' as 32-bit integers for maximum speed.)
    Dim r As Long
    Dim g As Long
    Dim b As Long
    r = (color And &HFF)
    g = ((color \ &H100) And &HFF)
    b = ((color \ &H10000) And &HFF)

    ' Now, arrange these byte values in the correct order (RRGGBB).
    color = ((r * &H10000) + (g * &H100) + b)

    ' And finally, format it as a hexadecimal string, left-padding with zeros as necessary.
    ' Note that if the red component value is large enough, padding does not need to be
    ' done, which allows us to skip an expensive string operation.
    If (r >= &H10) Then
        RgbToHex = Hex$(color)
    Else
        RgbToHex = Right$("00000" & Hex$(color), 6)
    End If
End Function

If this were C, I would guess that Roland's solution would probably be faster, since it does not involve a conditional branch (and conditional branches can be expensive when they are not properly predicted). However, since this is VB, I suspect that my code will be slightly faster, mainly because string operations are so incredibly expensive that it is worth a mispredicted branch penalty to elide one if at all possible. And, if I may compliment myself, I'd say that my solution is slightly more readable from a code-review perspective. (But either solution would require explicit comments describing the rationale.)

Notice, also, that in my implementation, I have a comment about choosing to keep the intermediate values in a 32-bit Long, even though they are just bytes and could be represented using the Byte type. The reason for this is that it is inherently faster to work with 32-bit values on 32-bit architectures, since they fit directly into the processor's native 32-bit wide registers. (This is why you should always use Long in VB 6, rather than the 16-bit Short type. You pay an additional penalty when working with 16-bit values!) If we'd tried to store them as Bytes, they'd take up less memory, but the realistic limitations of VB 6's optimizer mean that there will be some unnecessary conversion going on. If VB supported unsigned types, using them would open up even more potential for the optimizer to do its magic, especially when doing bit-twiddling operations; alas, it doesn't, so we're stuck with signed types.

Can we make it even faster?

One quick and easy way to speed up the code is to change the compiler flags. Too few people do this in VB 6, since it is so well hidden. When building your EXE (File → Make *.exe), click the Options button to bring up a dialog. Switch to the "Compile" tab. "Compile to Native Code" is selected by default, and so is "Optimize for Fast Code", which are both good for speed. However, you should also turn on "Favor Pentium Pro" and "Create Symbolic Debug Info".

Creating debug info is just a good idea, in case you ever have to debug your application, and it is impossible to generate it later. This is arguably less useful for a strictly VB programmer who wouldn't know how to use another debugger with a gun to his head, but it is a skill that is truly worth learning, and if you ever have to call in an expert, a PDB file is invaluable. It doesn't hurt anything to generate it and ignore it.

Why favor the Pentium Pro? Granted, this sounds like a hyper-specific option to favor a certain obsolete family of microprocessor, and indeed it was at the time that VB 5 was released, but it is actually the best general choice because all modern processors bear far more similarity to the Pentium Pro than they do to other generations of processors (with the exception of the Pentium 4, but VB 6 can't optimize for that anyway, and optimizing for PPro is still not a pessimization). The Pentium Pro was a unique processor in a number of ways, but two things were most important from an optimization sense. First, it supported out-of-order execution, where individual instructions could be dynamically re-ordered by the processor to overcome instruction-level data dependencies. Thus, it is better if the compiler generates shorter sequences of instructions (RISC-style), because these can be better reordered. Second, the Pentium Pro has a stall for certain partial-register accesses. The details are complicated and beyond the scope of this answer, but the important fact is that while the earlier Pentium didn't have these, all modern processors do, so having the optimizer generate code accordingly is a good idea.

Other important checkboxes are buried behind the "Advanced Optimizations" button. The UI tries to make these sound scary, but if you understand what they do, and your code has been truly and correctly debugged, some of them are worth enabling. Most obviously, you can turn on the bottom option, "Remove Safe Pentium FDIV Checks". The early Pentium processors with the infamous FDIV bug are long dead now, so this is just pointless baggage to carry around. The other options actually can be slightly unsafe, but it is worth considering turning on the "Remove Integer Overflow Checks" option, and possibly the "Remove Floating Point Error Checks" and "Allow Unrounded Floating Point Operations" options. These three options have a massive impact on the object code that is generated by the compiler, and enabling them can cause a correspondingly massive speed-up in the execution time of your code.

As an example, when I threw the "Remove Integer Overflow Checks" switch and recompiled my code, I saw that it had used shift instructions, instead of multiplication instructions, like I earlier wished that it had! Better yet, removing these overflow checks means that the compiler no longer emits conditional branches after each integer (or floating-point) operation, and even though these branches will be properly predicted to fall through most of the time, leaving them out entirely is still faster. This is a cheap way to make your code run a lot faster, without having to rewrite any of it.

For the hardcore among you, here is my annotated disassembly for the final code generated by the VB 6 compiler with optimizations enabled. You should be able to see some of what I'm talking about in terms of the rather-optimal bit-twiddling instructions, as well as the less-than-optimal string-manipulation code. But being completely overwhelmed is also normal.


Some opinionated advice:

I don't see why having two separate class, so I merge Kernel into App and rename it "AppKernel".

Then, I removed the "ready" method to replace it by the "create" from Kernel.
You don't need the "getType" function since your classes already define a "type"
I don't really understand why you want to keep a reference to your application's instances, so I remove it.
For me you should load the configuration from the outside with a dedicated "configuration" object.

EDIT: I added a method to create "singleton" application, I think this method will work but I am not 100% sure, so try it before.

All this transformation lead to something like this:

<?php
namespace App;

interface Executable
{
    public function run();
    public function ready();
}

class Configuration
{
    public static function load() {
        return [
            'key' => 'value'
        ];
    }
}

abstract class AppKernel implements Executable
{
    /**
     * Application name
     * @var string
     */
    protected $name = '';
    private static $instances = [];
    /**
     * Application configuration
     * @var array
     */
    protected $config = [];

    protected function __construct($name, Configuration $config)
    {
        $this->name = $name;
        $this->config = $config;
    }

    public static function create($name, Configuration $config)
    {
        if(!isset(static::$instance[$name]))
           static::$instance[$name] = new static($name, $config);

        return static::$instance[$name];
    }

    public function run()
    {

    }
}

class WebApplication extends AppKernel {}

class ConsoleApplication extends AppKernel {}

ConsoleApplication::create('name', configuration::load())->run();


user2023861 covers a lot of good ground, so I just have a couple more things to add.

First, instead of using parallel arrays, you might want to consider using a collection container like a List and filling it with objects.  Each line appears to a distinct record with a set of properties, so I would make them a simple Class:

public class Record
{
    public int Age { get; set; }
    public string Gender { get; set; }
    public string MaritalStatus { get; set; }
    public int District { get; set; }
}

That way, you don't have to hard code the size of the arrays that you are using, and you don't have to do any work to keep the related pieces of the record in synch (think what would happen if one of the arrays got sorted and the rest didn't).

Then, in your parser you can create objects for each record:

var records = new List<Record>();
var inputRecord = inFile.ReadLine();

while (inputRecord != null)
{
    var fields = inputRecord.Split(',');
    var currentRecord = new Record()
    {
        Age = int.Parse(fields[0]),
        Gender = fields[1],
        MaritalStatus = fields[2],
        District = int.Parse(fields[3])
    };

    records.Add(currentRecord);
    //...
}

You need to remember to dispose of  your FileStream and StreamReader if you are accessing them this way.  The easier and safer way to do this is with the using syntax, which will close and dispose of them at the ending braces.  I'd get into the habit of using this with any object with a .Dispose() method.

using (var fStream = new FileStream("test.txt", FileMode.Open, FileAccess.Read))
{
    using (var inFile = new StreamReader(fStream))
    {
        //Work with the file here
        //...
    } //inFile.Dispose() happens here automatically.
} //fStream.Dispose() happens here automatically.

This code...

    for (int x = 1; x <= 22; x++)
        for (int y = 0; y < districtData.Length; y++)
            if (districtData[y] == x)
                countDist[x]++;

...is begging for braces to make it easier to read.  It also help avoid potential errors.


Parsing a URL from a document and matching it from an array

Your code is simple and works, so I don't see any need to over-complicate things. It ofcourse depends on the sizes of the lists/data. But 500 doesn't seem so bad, performance wise.

It's good that you decided not to use regular expressions ([source])1
Using a CSS selector seems more appropriate. However it's prone to end up in errors if the site that provides the list changes its css.

In addition, I believe you have a small mistake with your indentation. Perhaps it's just a copy/paste error.

var arr = ['http://www.azaz.com', 'http://www.123.com'];
$("#links li").each(function () {
        var aa = $(this).find('a').attr('href');
        var found = $.inArray(aa, arr) > -1;
        if(found === true){
            $(this).append("true");
        }
});

instead of

var arr = ['http://www.azaz.com', 'http://www.123.com'];
        $("#links li").each(function () {
        var aa = $(this).find('a').attr('href');
        var found = $.inArray(aa, arr) > -1;
        if(found === true){
            $(this).append("true");
        }
});


You have exposed an injection vulnerability.

'WHERE Name like \'%'+accountName+'%\''

Any time you merge user input into your query, you should call String.escapeSingleQuotes, or better yet, use a dynamic binding.

// OK
searchQuery += 'WHERE Name LIKE \'%' + String.escapeSingleQuotes(accountName) + '%\'';

// BETTER
String fuzzySearchTerm = '%' + accountName + '%';
searchQuery += 'WHERE Name LIKE :fuzzySearchTerm';


The below points are in no particular order:
Extraction into Methods

The utility and the test should be broken up into methods, i.e., you should have a function String removeDuplicates(String), containing the logic for removing duplicates.

Manual Boxing

Unnecessary manual boxing to Character, just use char and let javac take care of it on its own (JDK1.5+ supports autoboxing of primitives).

Why LinkedHashSet?

A HashSet can be used just fine here - the order of the resulting deduplicated String is determined by the order of insertion of characters into the StringBuilder, not the HashSet. (Believe me, I checked. Here you can also: http://ideone.com/K9Ku2p)

Note that the add method of Sets return a boolean, true if the set did not already contain the element and it has been added successfully, or false if the element was already present in the Set. Exploiting this makes the call to Set.contains(...) redundant, see the example code.

Generics

Use generics. Don't use raw collections - they can violate type safety. In your case, you might not realise the immediate benefit of doing so, but it is a good practice when scaling to larger programs. Here, using generics is as simple as changing LinkedHashSet knownChars = new LinkedHashSet(); to LinkedHashSet<Character> knownChars = new LinkedHashSet<>(); (JDK 1.7+ to get the diamond type inference, otherwise it has to be LinkedHashSet<Character> knownChars = new LinkedHashSet<Character>();, JDK 1.5+)

Space-time tradeoffs

To minimize the number of reallocations of the underlying buffers of StringBuilder or HashSet, initialize them with a default capacity of the largest possible size they could have, which is the length of the input String. Use the constructors which have an int capacity parameter. See the example code for details.

To avoid a gotcha involving the load factor (a parameter which decides how full a HashSet should be before it is resized) of the HashSet when initializing the HashSet with capacity in point 6 (the Hashset may be prematurely resized), also set the load factor to 1.0f, using the new HashSet(int capacity, float loadFactor) constructor overload.

Miscellaneous

Type to interfaces, e.g., use Set<Character> knownChars = new LinkedHashSet<>(); instead of LinkedHashSet<Character> knownChars = new LinkedHashSet<>();. This makes your code in general more resilient to refactoring, you can use a different Set implementation at any time by changing one word instead of 2.

Qualify your method parameters with final if you are not going to reassign them in any way - granted, String being immutable makes this redundant, in the sense that any reassignments done to input in removeDuplicates will not affect test in main, but it's a good practice anyway.

Better output messages - see the example code for an example.

Better variable naming - it's already quite good, but try to use full words. See the example code.

Example Code (Ideone):
import java.util.Set;
import java.util.HashSet;

// Store in a file `StringUtilities.java`
public class StringUtilities
{

    public static void main(String[] args)
    {
        String test = "Banana";

        System.out.println("Test string \"" + test + "\" with duplicates removed is: \"" + removeDuplicates(test) + "\"");
    }

    public static String removeDuplicates(final String input) {
        Set<Character> knownCharacters = new HashSet<>(input.length(), 1.0f);
        StringBuilder noDuplicates = new StringBuilder(input.length());

        for(char character : input.toCharArray()){
            if(knownCharacters.add(character)){
                noDuplicates.append(character);
            }
        }
        return noDuplicates.toString();
    }
}


Naming

s is a poor name for a boolean array. I have no idea what s stands for. How about surroundingTiles?

Array ordering

Additionally, the order of the tiles seems strange to me. It's ... bottom, right, top, left, bottom right, top right, top left, bottom left. Without the image, I don't think I'd have gotten it. (For those wondering, it's non-diagonal, starting bottom, counter clockwise, then diagonal.) Any particular reason you have this layout within your array?

Magic numbers

Continuing from my previous point, this can be solved by naming the directions in constants:

var BOTTOM_INDEX = 0;
var RIGHT_INDEX = 1;
var TOP_INDEX = 2;
var LEFT_INDEX = 3;
var BOTTOMRIGHT_INDEX = 4;
var TOPRIGHT_INDEX = 5;
var TOPLEFT_INDEX = 6;
var BOTTOMLEFT_INDEX = 7;

I'm calling it Magic Numbers because without the image, I'd be left wondering which index is which. They're magic in that if they change, the code stops working. But why it has to be those numbers exactly is unknown... to the reader, at least.

Difference so far

var surroundingTiles = player.getSurrounding();
if (vY > 0) {
    if ((surroundingTiles[BOTTOM_INDEX] || (surroundingTiles[BOTTOMLEFT_INDEX] && xLocal < LOCAL_LEFT) || (surroundingTiles[BOTTOMRIGHT_INDEX] && xLocal > LOCAL_RIGHT)) && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }
} else if (vY < 0) {
    if ((surroundingTiles[TOP_INDEX] || (surroundingTiles[TOPLEFT_INDEX] && xLocal < LOCAL_LEFT) || (surroundingTiles[TOPRIGHT_INDEX] && xLocal > LOCAL_RIGHT)) && (yLocal + vY * dt) < LOCAL_LEFT) {
        vY = (LOCAL_LEFT - yLocal) / dt;
    }
}
if (vX < 0) {
    if ((surroundingTiles[LEFT_INDEX] || (surroundingTiles[BOTTOMLEFT_INDEX] && yLocal > LOCAL_RIGHT) || (surroundingTiles[TOPLEFT_INDEX] && yLocal < LOCAL_LEFT)) && (xLocal + vX * dt) < LOCAL_LEFT) {
        vX = (LOCAL_LEFT - xLocal) / dt;
    }
} else if (vX > 0) {
    if ((surroundingTiles[RIGHT_INDEX] || (surroundingTiles[BOTTOMRIGHT_INDEX] && yLocal > LOCAL_RIGHT) || (surroundingTiles[TOPRIGHT_INDEX] && yLocal < LOCAL_LEFT)) && (xLocal + vX * dt) > LOCAL_RIGHT) {
        vX = (LOCAL_RIGHT - xLocal) / dt;
    }
}

(Ckuhn also posted some naming changes, I suggest you add them in here as well.)

But Pim, if I do this, my if statements become very long!

Encapsulate Conditionals

Let's take a look at one of these paths.

var surroundingTiles = player.getSurrounding();
if (vY > 0) {
    if ((surroundingTiles[BOTTOM_INDEX] || (surroundingTiles[BOTTOMLEFT_INDEX] && xLocal < LOCAL_LEFT) || (surroundingTiles[BOTTOMRIGHT_INDEX] && xLocal > LOCAL_RIGHT)) && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }

if the vectorY is greater than 0... I guess that means if you're moving ... down... then...
if the bottom tile is solid or if either the bottom left tile is solid and the ... x something? or the bottom right tile is solid and x something but different...

It's way too confusing!
I can understand it, obviously, as I recognize the pattern (and you've given me an image for explanation). However, if I were to explain this code to someone else, I'd mentally recheck the code before continuing my explanation. I'd even manage to get it wrong at least once during my explanation ("and this checks for the upward movement, ... er, I mean the downward movement").

So, how can we fix that? Let's use English!

var surroundingTiles = player.getSurrounding();
if (movingDown) {
    if ((surroundingTiles[BOTTOM_INDEX] || (surroundingTiles[BOTTOMLEFT_INDEX] && passingLeftTileBorder) || (surroundingTiles[BOTTOMRIGHT_INDEX] && passingRightTileBorder)) && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }

It's still not clear enough. That's because I have no idea what (yLocal + vY * dt) > LOCAL_RIGHT means! Additionally, we still didn't get it clear enough.

var surroundingTiles = player.getSurrounding();
if (movingDown) {
    if ((hittingBottomTile || hittingBottomLeftTile || hittingBottomRightTile) && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }

Almost.

var surroundingTiles = player.getSurrounding();
if (movingDown) {
    if (hittingTileInBottomDirection && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }

Nice. It just got wondrously clean.
Sadly, computers are grumpy things that want everything specified, so we'll have to explain our human-readable English to them.

var movingDown = vY > 0;
if (movingDown) {
    var hittingBottomLeftTile = (surroundingTiles[BOTTOMLEFT_INDEX] && xLocal < LOCAL_LEFT);
    var hittingBottomRightTile = (surroundingTiles[BOTTOMRIGHT_INDEX] && xLocal > LOCAL_RIGHT);
    var hittingTileInBottomDirection = (surroundingTiles[BOTTOM_INDEX] || hittingBottomLeftTile || hittingBottomRightTile);
    if (hittingTileInBottomDirection && (yLocal + vY * dt) > LOCAL_RIGHT) {
        vY = (LOCAL_RIGHT - yLocal) / dt;
    }

At this point, you could consider shifting certain parts of the logic towards a function which does simple calculations. Your call. I'd prefer that to this inline logic, because if you use the functions, you can write this function on a different level of abstraction. That is, you can write English code consisting entirely of function calls. At that point, if you made a mistake, you'll spot it instantly. Because if you have a function that looks like this...

function checkForCollision(/*arguments omitted*/) {
    checkCollisionInDirection(LEFT);
    checkCollisionInDirection(RIGHT);
    checkCollisionInDirection(TOP);
    checkCollisionInDirection(LEFT);
}

The bug is obvious.

I'll leave the location of variable definitions and the (yLocal + vY * dt) > LOCAL_RIGHT to other answerers.


#include <iostream>
#include <ostream>
#include <string>
#include <vector>

class Return_Self_Test {
    std::string name;

    public:
    Return_Self_Test(std::string const& name_in) : name(name_in) { }

    std::string const& get_name() const noexcept {
        return name;
    }

    std::vector<Return_Self_Test> get_in_vector() const {

        using std::literals::string_literals::operator""s;

        std::vector<Return_Self_Test> rst;

        rst.emplace_back(Return_Self_Test("new one 1"s));
        rst.emplace_back(*this);
        rst.emplace_back(Return_Self_Test("new one 2"s));

        return rst;
    }
};

std::ostream& operator<<(std::ostream& os, Return_Self_Test const& rst) {
    return os << "Name: " << rst.get_name();
}

void return_self_test() {

    Return_Self_Test rst_a("Original");
    auto a_vect = rst_a.get_in_vector();

    for (size_t i = 0; i < a_vect.size(); i++) {
        std::cout << std::to_string(i) + ": " << a_vect[i] << '\n';
    }
}

This is my suggestion for a slightly more organized solution of your problem. Let's walk this through and see what I did differently from you, and why.

Constructors

C++ is actually reasonably nice when it comes to what special member functions have to be declared by the user and which ones are generated by the compiler. For most simple classes, you actually don't need to define anything at all! Copy constructor, move constructor, copy assignment operator, move assignment operator and destructor are all implicitly defined in your case, so I went ahead and removed your copy constructor definition.

You should also notice that I removed that pointer-to-self constructor you defined, which you also expressed concerns about. I have good news for you: This constructor is completely unnecessary! In fact, your original code does not even use it, and neither does mine.

Where is to_string?

I don't know why you felt compelled to write your own version of this function, but the standard provides something with the exact same functionality in the string header (well, apart from the fact that std::to_string will downright reject anything that is not a number).

Still, let's take some time and talk about your version of this common functionality. Three things come to my mind here:

Why do you take number by const reference? You are expecting numeric types, which are all small enough to be efficiently passed as values.
Having a normal if on a compile-time type trait is an slightly bad, if you have access to C++17. In that case, this should clearly be if constexpr (...).
Regard and handle errors as errors. Don't return some ill-defined dummy value if your function does not succeed. There are many ways to signal an error, from throwing an exception to returning an std::optional. In this special case, however, the error is actually diagnosable at compile time. Although this makes point two useless, check your type at compile time and SFINAE out if it is not a number. You will save yourself a lot of debugging headaches down the line.

Doing I/O Correctly

Maybe you have been wondering: "Hey, where did my output method go?". Probably, you have already realized that I turned it into a non-member operator<<, and I do have good reasons to do so:

Imagine you are working with a huge project with thousands and thousand of classes. Your task is to implement a logging system: Sometimes, things go wrong, and it is your task to collect all the error messages that result from this, order them by certain criteria, and send them to various outputs (e.g. a log file, stdout, a web socket). However, all classes only offer a single output() method, just as Return_Self_Test does, which writes a message to std::cout.

So you spend the next half a year doing the most boring, mind-numbing refactoring work anyone could possibly imagine.

Do you understand what I am getting at here? You are basically loading a gun to shoot yourself in the foot with in a few years when you write code like this. C++ offers a whole lot of flexibility through the whole istream/ostream concept, and you currently use exactly nothing of it.

This is why you should start writing operator<< instead of your own output or write or whatever methods. This makes integrating output routines into an already existing context much more pleasant, as you can just write these values to std::cout as you are used to with all of the basic types. Furthermore, using a general std::ostream instead of std::cout will save you a lot of suffering when you find yourself in a situation where you actually have to write to something that is not the standard output.


You can atomically write to a file if you are working with a threadsafe queue.

#!/usr/bin/env perl

use warnings FATAL => 'all';
use strict;
use Time::HiRes qw(time nanosleep);
use threads;
use Thread::Queue;

my $logQ = Thread::Queue->new();

my $consumer = threads->new(\&_logConsumer);

my @producer;
push(@producer, threads->new(\&_logProducer)) for (1..10);
$_->join() foreach @producer;

$logQ->enqueue('STOP');

$consumer->join();

sub _logProducer {

  for (1..10) {
    $logQ->enqueue(sprintf('[%-17s:%04i]', time(), threads->tid()));
    nanosleep(int(rand(10_000)));
  }

  return;
}

sub _logConsumer {

  open(my $fh, '>', '/tmp/atomic.log')
     or die 'Cannot open log file, stopped';

  my $running = 1;
  while($running) {
    if (defined(my $item = $logQ->dequeue())) {
      $running = undef if $item eq 'STOP';
      print $fh "$item\n";
    }
  }
  close($fh);

  return;
}

The output of /tmp/atomic.log looks like:

[1526568957.83079 :0011]
[1526568957.8308  :0006]
[1526568957.83081 :0009]
[1526568957.83082 :0010]
[1526568957.83087 :0008]


There are some problems with this implementation:

if both the query in loadData fail, res.status(500).end(err.message) is run twice so you will get an error RESPONSE ALREADY CLOSED that could lead to server crash, and this must be avoided
you are not using a linter on your code. I can say that because you have the error parameter in the callback, but in the code, you wrote ..end(err.message), so adopt a linter to see these error before they happen in production that would cause a crash of your application since err would be undefined
every request adds in the memory heap the functions loadData, deletePostSchemaReords and deleteCommentRecords causing pressure on the garbage collector and slowing down your endpoints and this can be voided
a lot of code replicated that must be avoided to have a nice and maintainable endpoint
fs.unlinkSync kills the performance in an API endpoint
deleteCommentRecords() is called for every comments_image_output but this would execute comments_image_output.length times the same query, this is a functional error
in deleteCommentRecords() a transaction begins and the immediately committed so it is not adding any performance gain: a transaction works best when there are multiple query to execute across multiple tables
the loadData function is deleting rows from DB, so the name is misbehaviour
in deletePostSchemaReords there is only a query without the transaction so the rollback is ineffective
the response object should be managed by one entity otherwise there is too much coupling between general functions (like delete an array of files) and the HTTP protocol

Here how I would proceed with the refactor.

I used the callback style (instead of async/await) since you are not using promises
I assume there is a db and a uploadDir global objects - since are not in the code example

router.delete('/:id', (req, res) => {
  loadData(req.params.id, (err, files) => {
    if (err) { return res.status(500).end(err.message) }

    // if both query are successful delete from the database
    deleteAll(req.params.id, (err) => {
      if (err) { return res.status(500).end(err.message) }

      res.redirect(303, '/admin/posts') // response to the client first

      // the database deletion is OK, now delete the files quitely
      const deleteFileArray = files.comment.concat(files.post)
      deleteFiles(deleteFileArray, (err) => {
        if (err) {
          console.log('ops failed to delete files, but who cares?')
        }
      })
    })
  })
})

function loadData (postId, callback) {
  let runs = 0
  const output = { comment: null, post: null, error: null }

  db.query('SELECT image FROM commentschema WHERE postID = ?', postId, processQueryResult.bind(null, 'comment', 'image'))
  db.query('SELECT filename FROM PostSchema WHERE id = ?', postId, processQueryResult.bind(null, 'post', 'filename'))

  // this function will be executed twice an manage only one callback call
  function processQueryResult (responseType, columnName, error, images) {
    if (error) {
      output.error = error
    } else {
      output[responseType] = images.map(row => uploadDir + row[columnName])
    }

    if (++runs === 2) { // call the callback with the sum of the files to delete
      callback(output.error, output)
    }
  }
}

function deleteAll (postId, callback) {
  // Delete PostSchema records
  db.beginTransaction(function (err) {
    if (err) return callback(err)

    // Delete comment section records
    db.query('DELETE FROM commentSchema WHERE PostID = ?', postId, (err) => {
      if (err) { return db.rollback(callback.bind(null, err)) }

      db.query('DELETE FROM postschema where id = ?', postId, (err) => {
        if (err) { return db.rollback(callback.bind(null, err)) }

        db.commit((err) => {
          if (err) { return db.rollback(callback.bind(null, err)) }
          console.log('Transaction Completed Successfully.')
          callback()
        })
      })
    })
  })
}

function deleteFiles (files, callback) {
  let i = files.length
  files.map(function (filepath) {
    fs.unlink(filepath, function (err) {
      if (err) {
        callback(err)
      } else if (--i <= 0) {
        callback(null)
      }
    })
  })
}
```


Consider using a different naming convention for your data members and methods, such as camelCase or snake_case.  Your user-defined types are already uppercase, which is okay.  Whichever you choose, it's more readable to keep them separate.
The push/pop methods here imply that this is a stack implementation, but a linked list should be capable of inserting or removing a node at any location in the list.  Consider adding additional functions for this.  For an idea of typical linked list functions, read this.
Since you're using a list class, you should have a size member to maintain.  Your Size() method is calculating the size at each call by traversing, which is O(n).

Instead, have a size data member and update it with other operations:

initialize to 0 in the initializer list
increment with each push
decrement with each pop
reset to 0 with each clear

When you call Size(), it should just return the data member value, which is O(1).

It should also return a std::size_t.  It is closest to the return type used in STL containers, and a very large list size may not fit inside an unsigned int.
Instead of having a return in PushFront(), put the last two lines into an else block.
Shouldn't popBack() check tail if PopFront() checks head?  Although they may be pointing to the same node if there's only one node, but the intent is more clear this way.
You should probably also have a Front() and Back() that return a T const&, in case the reference will not be modified or a const value is needed.
You should have some way of displaying the list.  For that, consider overloading operator<< for the List class (instead of a display function), allowing you to do this:

List list;
std::cout << list;

You could also overload Node's operator, allowing you to output a node within the List class.
std::out_of_range is defined in <stdexcept>, not <exception>.


This seems unnecessary complicated. Why not just have one simple class template:

template <int DIM>
class ClassName {
public:
    using array = std::array<double, DIM>;

    void somethingDimensionless(const array& dblArray) const;

    template <int D = DIM,
              typename = std::enable_if_t<(D == 1)>>
    void somethingIn1D() const {
        ...
    }
};

And use it directly:

ClassName<1> oneD;
ClassName<2> twoD;

We use SFINAE instead of a static_assert in case you want to write a type trait to check for the existence of somethingIn1D. With a static_assert, ClassName<2>{}.somethingIn1D() wouldn't compile but overload resultion would still find it.


AWS Lambda Python function, to enable / disable access to a VPC environment

A recommendation that I give with most of my reviews, and which is relevant here, is a perusal of PEP 8, the official style guide for Python. Many of my comments below will reference that document.

import boto3, os

PEP 8 has a few things to say about this (in the section entitled Imports). First, generally you shouldn't put multiple modules on the same line. Next, third-party modules should be distinguished from built-ins, preferably with a blank line (and local application modules after). In addition, I like to alphabetize my imports within each group. It can prevent duplicates. So I would do it like this:

import os

import boto3

region = os.environ['PFregion']
security_group_id = os.environ['PFSG']
bastion_iid = os.environ['PFbastion_iid']
aws_profile = 'profile_name'

I have several problems with this. For one thing, os has a shortcut function for accessing environment variables: os.getenv. I would also pass these as arguments to lambda_handler instead of using global variables. This gives the option of calling the function from another module or calling it multiple times without the need of setting environment variables.

The if __name__ == '__main__': block should be where those variables are gotten. As a nice touch, you could use argparse to add commandline arguments as an alternative to environment variables. I would probably do it something like this:

# At the top with your other imports
from argparse import ArgumentParser

# In `if __name == '__main__':`
parser = ArgumentParser(description="Your program description")
parser.add_argument('-r', '--region', description='PF region')
 # (Repeat for other arguments)

args = parser.parse_args()

Then you can pass something like args.region or os.getenv('PFregion') to your function. That gives the command line option as the decision-maker, but it falls back on the environment variable.

def lambda_handler(event, context):
    if (__name__ == "__main__"):

This is a worker function; it shouldn't care what is calling it. I would move the block outside the function and pass the relevant variables as arguments. You could even use something like:

# Though because of my previous recommendation, this function would have more arguments.
def lambda_handler(event, context, session=boto3):
    ec2_client = session.client('ec2', region_name=region)
    ec2_resx = session.resource('ec2', region_name=region)

Then your if __name__ == '__main__': block could simply pass the session as an argument, but the default without a session still works.

event = { "up" : "true", "desc" : "this is a description field", "dry_run" : "false" }

I would add these options to the environment variable and command line options.

Python has its own booleans. Use them: "up": True.

Another styling comment: I wouldn't put spaces on both sides of the braces. PEP 8 comments on this.

I also noticed that you never use event['desc'] or event['dry_run']. Why then are they ever defined?


Calculating some worst-case values for angles in an interval

Your code already seems to do only the steps necessary, slow performance seems to be the limitation of VBA.

You may do some minor improvements however:

Select Case i

You don't need to check conditions here, it's a simple Mod operation:
l = Application.Evaluate("=MOD(" & i & ",360)")

Formulas

Your calculations contains a lot of duplicates, you can use temporary variables to reduce number of calculations:

t1 = AmplCo(FileCounter-1, AktBeam,l,k) * AmplCo(FileCounter, AktBeam,l,k)
t2 = PhaseCo(FileCounter-1, AktBeam,l,k) - PhaseCo(FileCounter, AktBeam,l,k)
t3 = AmplCr(FileCounter-1, AktBeam,l,k) * AmplCr(FileCounter, AktBeam,l,k)
t4 = PhaseCr(FileCounter-1, AktBeam,l,k) - PhaseCr(FileCounter, AktBeam,l,k)

A = A + t1 * Cos(t2) + t3 * Cos(t4)
B = B + t1 * Sin(t2) + t3 * Sin(t4)

t5 = (AmplCo(FileCounter-1, AktBeam,l,k)^2 + AmplCr(FileCounter-1, AktBeam,l,k)^2)
t6 = (AmplCo(FileCounter, AktBeam,l,k)^2 + AmplCr(FileCounter, AktBeam,l,k)^2)

C = C + t5
D = D + t6

BT_Worst = BT_Worst + t5 / t6

This halves the number of array accesses in your code (so best case you can get double speed).

As I've written already, there are limitations in VBA too. Further improvement could be done implementing your code in e.g. Visual Studio and compile as an Excel add-in. (That case you could avoid run time compilation and debugging which are the biggest issue in VBA).


Naming

Handler is too generic and doesn't explain what this class is about. GameHandler would be better. Or maybe GameManager even better.

Methods should be named camelCase, so this violates the convention: PrintGuesses

The gameOver and gameWin methods' main job is to print messages.
So it would be better to name them as such, for example printGameOverMessage, printGameWinMessage.

Visibility

A good general rule of thumb:
you shouldn't manipulate the fields of objects directly like this: gameHandler.gameOver = true

All the fields in Handler should be private:

They should not be writable by other classes
Other classes should not need to see these implementation details

This is related to good encapsulation and information hiding:
other classes should not need to know how the game handler works,
they should be able to interact with it using public interface methods.

General coding style

The formatting is a bit inconsistent. Use your IDE's function to reformat the code nicely and consistently.
The empty public constructor of Handler is unnecessary, you can delete it, the compiler will add it automatically


Yes. It seems like a bad design or I would say not thought through given that you're building a library project which will be used by other apps.

First of all,
in your library initialization, you should ask for Application reference rather than Context reference.

For example,

if your library has an init method like this,

MyLibrary.init(Context applicationContext);

then it should be converted to accept Application object like this,

MyLibrary.init(Application application);

Then,

inside that init method, you should just register your class which is implementing Application.ActivityLifecycleCallbacks.

application.registerActivityLifecycleCallbacks(ActivityLifecycleHelper.getInstance());

Make sure your class is a singleton. In your example, your ActivityLifecycleHelper class is not a singleton which is definitely a bad design pattern given that you're dealing with global level callbacks and want to initialize only once.

It might look like this,

public class ActivityLifecycleHelper implements Application.ActivityLifecycleCallbacks {
private static ActivityLifecycleHelper ourInstance = new ActivityLifecycleHelper();

private ActivityLifecycleHelper() {
}

public static ActivityLifecycleHelper getInstance() {
    return ourInstance;
}

@Override
public void onActivityCreated(Activity activity, Bundle bundle) {
}

@Override
public void onActivityStarted(Activity activity) {
}

@Override
public void onActivityResumed(Activity activity) {
}

@Override
public void onActivityPaused(Activity activity) {
}

@Override
public void onActivityStopped(Activity activity) {
}

@Override
public void onActivitySaveInstanceState(Activity activity, Bundle bundle) {

}

@Override
public void onActivityDestroyed(Activity activity) {

}
}

Also, I don't understand why you have two classes here. What's the use case of Usage class ? Something seems wrong in this two class design.

I hope this helps. Let me know if you want me to elaborate anything.


I have made some changes to the code I feel make things more clear, I will post them here in case someone needs something similar.

Code below is used in my function and is work of Freek van Tienen (part of open source software Paparazzi):

struct image_t {
  enum image_type type;   ///< The image type
  uint16_t w;             ///< Image width
  uint16_t h;             ///< Image height
  struct timeval ts;      ///< The timestamp of creation

  uint8_t buf_idx;        ///< Buffer index for V4L2 freeing
  uint32_t buf_size;      ///< The buffer size
  void *buf;              ///< Image buffer (depending on the image_type)
};

void image_create(struct image_t *img, uint16_t width, uint16_t height, enum image_type type)
{
  // Set the variables
  img->type = type;
  img->w = width;
  img->h = height;

  // Depending on the type the size differs
  if (type == IMAGE_YUV422) {
    img->buf_size = sizeof(uint8_t) * 2 * width * height;
  } else if (type == IMAGE_JPEG) {
    img->buf_size = sizeof(uint8_t) * 2 * width * height;  // At maximum quality this is enough
  } else if (type == IMAGE_GRADIENT) {
    img->buf_size = sizeof(int16_t) * width * height;
  } else {
    img->buf_size = sizeof(uint8_t) * width * height;
  }

  img->buf = malloc(img->buf_size);
}

My code for image padding:

void pad_image(struct image_t *input, struct image_t *output, uint8_t expand)
{
    image_create(output, input->w + 2 * expand, input->h + 2 * expand, input->type);

    uint8_t *input_buf = (uint8_t *)input->buf;
    uint8_t *output_buf = (uint8_t *)output->buf;

    // Skip first `expand` rows, iterate through next input->h rows
    for (uint16_t i = expand; i != (output->h - expand); i++){

        // Mirror first `expand` columns
        for (uint8_t j = 0; j != expand; j++)
            output_buf[i * output->w + (expand - 1 - j)] = input_buf[(i - expand) * input->w + j];

        // Copy corresponding row values from input image
        memcpy(&output_buf[i * output->w + expand], &input_buf[(i - expand) * input->w], sizeof(uint8_t) * input->w);

        // Mirror last `expand` columns
        for (uint8_t j = 0; j != expand; j++)
            output_buf[i * output->w + output->w - expand + j] = output_buf[i * output->w + output->w - expand -1 - j];
    }

    // Mirror first `expand` and last `expand` rows
    for (uint8_t i = 0; i != expand; i++){
        memcpy(&output_buf[(expand - 1) * output->w - i * output->w], &output_buf[expand * output->w + i * output->w], sizeof(uint8_t) * output->w);
        memcpy(&output_buf[(output->h - expand) * output->w + i * output->w], &output_buf[(output->h - expand - 1) * output->w - i * output->w], sizeof(uint8_t) * output->w);
    }
}


Given n input strings and m query strings, find each query frequency in the list of input strings

Can I do it in a better way?

From the time complexity or space complexity your solution is good enough. Your store all your string frequencies beforehand so that to retrieve a frequency by any given string in O(1) time later. Also, it passes all the test cases so it's a good sign too.

Below are a couple of concerns regarding other aspects of your code.

Variable Naming

Your choice of variable names should be improved. For instance, Map<String, Integer> counter doesn't really reflect for what it stands for. I would call it stringFrequencyMap or stringCountMap.

Also, result sounds too generic here. How about queryResults?

I'll leave it up to you to think about other variable names you have (luckily not many left :) ).

Static method

I guess you've kept this method static as it was like this by default and to avoid creating an instance of your Solution class in the main() method. While it's fine for a small challenge like yours, generally there should be a good reason to add static to your method.

Improvements

  Can this be simplified in Java-8, 11 or later?

Of course, if we just use JAVA 8 then we can take advantage of streams and write a solution as :

static long[] matchingStrings(String[] strings, String[] queries) {
    Map<String, Long> stringCountMap = Arrays.stream(strings).collect(Collectors.groupingBy(Function.identity(), counting()));

    return Arrays.stream(queries).mapToLong(query -> stringCountMap.getOrDefault(query, 0L)).toArray();
}

As you can see, we do this in 2 steps. First, we calculate a frequency map and then calculate an array of results using streams again. Please note that I changed the return type from int[] to long[].

UPDATE

Since there was a question why I've used Map<String, Long> rather than Map<String, Integer> - well, Long can hold bigger numbers. But since it's irrelevant for this problem here's a solution for Map<String, Integer>:

int[] matchingStrings(String[] strings, String[] queries) {
    Map<String, Integer> stringCountMap = Arrays.stream(strings).collect(Collectors.groupingBy(Function.identity(), summingInt(x -> 1)));

    return Arrays.stream(queries).mapToInt(query -> stringCountMap.getOrDefault(query, 0)).toArray();
}


I may not be able to review the point you specifically ask for, but I'll go for a general review:

Omit public and abstract keyword from interfaces, it is implicit.
Be consistent with spacing out your syntax. You for example have public abstract void execute ( );, whereas it should be void execute();, some strings in your program also could have spacing fixed.
Don't start instance variables with m_, perhaps this is common practice from another background, but not in Java. You seem to adhere camelCasing elsewhere though.
Make parameters final where possible. It gives compiler errors if you accidentally change the primitive or the reference to an object.
Use generics, in Agent you specify m_ordersQueue as new ArrayList(), you want to use generics. If all types of objects can be stored, then use new ArrayList<Object>(). I see that you have forgotten to declare the type of the variable, using Java 7's Diamond Operator, it would be private final List<Object> ordersQueue = new ArrayList<>();, also notice that I define only List<Object> as type, as you always want to use interfaces to declare types if possible.
Give variables descrptive names, bsc and ssc are not descriptive.
Lastly, I would consider using a Queue<Object> for the ordersQueue in Agent, the name implies that you want a queue implementation, yet you are using a list implemention.

The good news is that you seem to be following quite some paradigms correctly and you understand OOP quite reasonably, yet you do need to improve on some points.


Using fetch() and a new Promise object to get API results

A few comments:

1) fetch already returns a promise, which means this:

new Promise((resolve, reject) => {
  return fetch(url).then(response => {
    if (response.ok) {
      resolve(response)
    } else {
      reject(new Error('error'))
    }
  }, error => {
    reject(new Error(error.message))
  })
})

Is pretty much the same as:

fetch(url).then(response => {
  if (response.ok) {
    return response
  }
  return Promise.reject(Error('error'))
}).catch(error => {
  return Promise.reject(Error(error.message))
})

2) Keeping this in mind you can simplify your code with early returns and fewer branches:

function get(url) {
  return fetch(url).then(response => {
    if (response.ok) {
      const contentType = response.headers.get('Content-Type') || '';

      if (contentType.includes('application/json')) {
        return response.json().catch(error => {
          return Promise.reject(new ResponseError('Invalid JSON: ' + error.message));
        });
      }

      if (contentType.includes('text/html')) {
        return response.text().then(html => {
          return {
            page_type: 'generic',
            html: html
          };
        }).catch(error => {
          return Promise.reject(new ResponseError('HTML error: ' + error.message));
        })
      }

      return Promise.reject(new ResponseError('Invalid content type: ' + contentType));
    }

    if (response.status == 404) {
      return Promise.reject(new NotFoundError('Page not found: ' + url));
    }

    return Promise.reject(new HttpError('HTTP error: ' + response.status));
  }).catch(error => {
    return Promise.reject(new NetworkError(error.message));
  });
}


function count(from, to, targetElem) {
    targetElem.innerHTML = 'Total wordcount: ' + from;

    if (from == to) return;

    from < to ? from++ : from--;

    var changeTime = Math.max(20, 1000 - Math.abs(from - to)) / 2;

    setTimeout(function() {count(from, to, target);}, changeTime);
}

count(50, 0, document.getElementById("t"));

A few notes:

avoid global variables to conserve state - use function arguments instead
always use var to declare variables. Otherwise they are in the global scope and you don't want this
added error checking (i.e. whether values are numeric and target is valid) might not be a bad idea, I left it out for clarity here
return early on known conditions, this reduces complexity in the function body
the ternary operator condition ? ifTrue : ifFalse can be used in other ways than assigning a value


User Authentication/Permissions for PHP MySQL CRUD

Loops

Why are you using a for loop? I would just use a foreach loop, its much more efficient, especially for what you are doing here.

foreach(self::$table_names as $table_name) {
    //etc...
}

Strings

The following are micro-optimizations, but ones that are usually accepted as standard practice.

Single quotes should be used if no PHP processing is to be performed on a string. In other words, there are no PHP variables in the string. This is a micro optimization because it doesn't really add any noticeable overhead to your script. However, doing this you'll notice that you wont have to escape quotes nearly as frequently as you would have to if you started with single quotes. This is especially handy when dealing with HTML or XML attributes, which I'll get into soon.

$form .= $table_name . ':
';

Double quotes should be used for strings that require PHP processing.

$form .= "$table_name:
";

HTML/XML Attributes

While most browsers accept it, it is still improper syntax to use single quotes on HTML/XML tag attributes. XML will actually produce errors. Either escape the double quotes or escape the string and only go back into PHP for the variables.

$form .= $action . ": <input type=\"checkbox\" name=\"permissions[$table_name][$action ]\"";
//OR
<input type="checkbox" name="permissions[<?php echo $table_name; ?>][<?php echo $action; ?>]"

Sanitizing and Validating

You shouldn't handle raw POST data. Always sanitize and validate it. Check out PHP's filter_input() function. That goes right along with what Shaad said about passing serialized data to your tables too. Its not a good idea, especially if it hasn't been sanitized and validated.

Comparisons

I would use absolute equality comparisons when checking for current permissions rather than loose comparison as your $actions table should only have boolean values. Also the quotes around an integer is unnecessary, unless you are comparing a string with absolute equality.

$form .= ($current_permissions[$table_name][$action] === TRUE ? " checked =\"checked\"" : "");


class MUserNew | Add DRY, remove constants to mysql defaults

Where do I begin?

Simplest first. Make sure you assign your constructor a state (public, private, or protected). Most likely public.

Now... Where are all these extra properties coming from? $ISharedObject is not even remotely similar to anything else, so it isn't a typo. And its not defined as a class property, so I can't even be sure this is supposed to be here. The class you provide does not extend a parent class, so it isn't from there. It just appeared in invoke() out of no where. The method it uses suggests that it is most likely a $MessageObject but I don't know.

It looks like you've either copy-pasted this all together, or had a collaboration with someone else and you've crossed your naming schemes. $MessageObject and $TextObject looks like they should be $message_object and $text_object respectively. They should be renamed as such or vice-versa. It is probably easier to rename where they are defined, less to change, but up to you.

You have a $not_validated and $validated variable, of which only the first was defined.

If checkEmail() only ever returns a boolean, like its name suggests, then there is no need for absolute equality operators "===". Just if( $email_is_unique ). If it returns something other than a boolean, then it is doing too much and needs to be separated into multiple functions.

Arrays and loops are your best friend for repititive code.

$patterns = array(
    'name',
    'email',
    'pass',
);

foreach( $patterns AS $pattern ) {
    if( !$this->TextObject->checkPattern( $pattern ) ) {
        return $this->MessageObject->get( $pattern );
    }
}
return true;

Change these first few things and I'll take another look, but right now this is very confusing.

UPDATE

"This has irked me for a long time...code that is DRY ( Don't Repeat Yourself )...is less efficient then code that has some repetition. Dry is a good concept unless taken to extreme...as far as looping goes...either way is fine I think....I'll add the loop in as a matter of preference even though a tad bit less efficient."

How do you figure this is less efficient?

$patterns = array( 'name', 'email', 'pass' );
foreach( $patterns AS $pattern )
{
    if( !$this->$text_object->checkPattern( $pattern ) )
    {
        return $this->$message_object->get( $pattern );
    }
}

Than this?

if( !$this->$text_object->checkPattern( 'name' ) )
{
    return $this->$message_object->get( 'name' );
}
if( !$this->$text_object->checkPattern( 'email' ) )
{
    return $this->$message_object->get( 'email' );
}
if( !$this->$text_object->checkPattern( 'pass' ) )
{
    return $this->$message_object->get( 'pass' );
}

The first reduces the amount of code written, which in turn reduces the amount of times you can make mistakes, which in turn reduces the amount of lines you'll have to wade through should you ever need to debug it. It also automates similar tasks for any parameters you wish to throw at it so that if that task should ever need to change, you'll only ever have to do so once. Or should you ever wish to add to it, you only need to add a parameter to an array. Where did you hear that DRY is inefficient? I admit abusing it could get ridiculous, but you have to go out of your way to accomplish that.

Anyways, here's what I have for your update.

You still have that issue with variables and properties appearing out of thin air. $validated I'm assuming should be $not_validated. Though I, personally, would switch that around. I like imagining my variables like this to be asking a question "validated?" and not "telling" you its state. But thats a preference. $TextObject should probably be $text_object.

Another thing I just noticed. You are declaring your properties like so: $this->$text_object; When they should be declared like so: $this->text_object; The first is called a variable variable. It states that whatever the value of $text_object is will be declared as the name of a new property. First of all, these are cosidered bad form, mostly because they are impossible to track and make your code unuseable by anyone but you. Not really, but pretty damn close, not even IDE's can track these. Here it is explained in code, hopefully more clear.

$a = 'apple';
$b = 'banana';
$this->a = $b;
$this->$a = 'orange';
$$a = 'tangerine';

echo $a;//apple
echo $b;//banana
echo $this->a;//banana
echo $this->apple;//orange
echo $apple;//tangerine
//$this->apple and $apple just magically appeared, this is because they were set from the value of $a.

You have a couple of really long statements that could be made more legible. There are a few ways you can do this. The simplest is to bring the parameters out of the method call and convert them to variables in the local scope. This is pretty common and helps clean up code quite a bit.

$email = array( $this->TextObject->get('email') );
if( $this->$database_object->_pdoQuery( 'single', 'signup_check', $email ) )

Another way, usually used in conjunction with the previous, is to use PHP's helpful nature to your advantage. PHP does not care about whitespace, so you can drop long statements like this to new lines and indent to your hearts content.

$this->$database_object->_pdoQuery(
    'single',
    'signup_insert',
    array(
        '',
        $this->TextObject->get('name'),
        $this->TextObject->get('email'),
        $this->TextObject->get('pass'),
        0,
        0
    )
);
//OR
$name = $this->TextObject->get('name');
$email = $this->TextObject->get('email');
$pass = $this->TextObject->get('pass');
$array = array(
    '',
    $name,
    $email,
    $pass,
    0,
    0
);
$this->$database_object->_pdoQuery(
    'single',
    'signup_insert',
    $array
);

Last thing I want to mention is magic numbers. Those are numbers that appear out of thin air and could mean anything. Much like those variable variables I mentioned earlier, they are almost impossible to track down. To you, as the author, you probably know what these are at a glance. But to someone reading your code for the first time, they will not have a clue. This could even be you in a few months after you've started working on other projects. Take a look at the code above. Those zeroes "0" and empty strings '' don't mean anything. They just exist. They are magic. Declare them and set them as variables so people know what they do.


Don't ask if the user wants to play the first time
If the user started your game, then of course they want to play it, otherwise they wouldn't have started it to begin with. So don't ask and go to the intro immediately. If they started your game in error, they can always quit it by closing the window, pressing control-C or something like that.
You will overflow the stack, eventually
For every action that does not end the game, you just call another function, but you don't return from a function. This means your call stack will grow indefinitely. With the gigabytes of RAM we have in our computers nowadays, you might not notice this mistake, but on the eight-bitters of the previous century, your game would run out of memory very quickly because of this.
Generally, you want to have a main loop that handles the input, and that advances the state based on your input. For example, you could write it like so:
def intro():
    print('You wake up...')
    ...
    choice = input('>>> ')
    if choice in answer_A:
        print("...");
        return "game_over"
    elif choice in answer_B:
        return "castle"
    ...

def main_loop():
    state = "intro"

    while state != "end":
        if state == "intro":
            state = intro()
        elif state == "castle":
            state = option_castle()
        ...
        elif state == "game_over":
            again = input('Do you want to play again? Y or N  ')
            if again in yes:
                state = "intro"

main_loop()

The above is just an illustration of the idea. To do it properly, you would probably use an enum for the state, and possibly have a map of states to functions so you can simplify the whole loop. For example:
from enum import Enum

class State(Enum):
    INTRO = 1
    CASTLE = 2
    ...
    GAME_OVER = -1
    END = -2

def intro():
    ...

def option_castle():
    ...

def game_over():
    print('Game over.')
    again = input('Do you want to play again? Y or N  ')
    if again in yes:
        return State.INTRO
    else
        return State.QUIT

scenarios = {
    State.INTRO: intro,
    State.CASTLE: option_castle,
    ...
    State.GAME_OVER: game_over,
}

def main_loop():
    state = State.INTRO

    while state != State.END:
        state = scenarios[state]()

main_loop();

Consider not sleeping before showing possible choices
The calls to time.sleep(1) are not needed for the game, and just make it so the player has to wait unncessarily before being able to read the choices. I would just avoid this.
The game is quite rude
It might seem funny to you, but if I was a player, and accidentally typed in the wrong character, and got told that I was an idiot, my appreciation of the game would drop significantly. Also, being told that garlic doesn't work because that's just a story book thing is very annoying, since the whole concept of vampires comes from a story book to begin with.


From a short review;

I advise avoiding null, you could either not define the member or use undefined
busiestPeriod is a really long name, given how often you use it
You really only need to track the log entry with the most visitors, the start of the period would be timestamp of the entry before that
This: busiestPeriod.visitors = v.type === "enter" ?
  busiestPeriod.visitors + v.count :
  busiestPeriod.visitors - v.count; could be

busiestPeriod.visitors += (v.type == "enter" ? v.count : - v.count);

or even

busiestPeriod.visitors += (v.type == "enter" ? 1 : -1) * v.count;

This is my counter-proposal:

function findBusiestTime(logs){

  function analyzeLogEntry(acc, log, index){
    if(log.type == "enter"){
      acc.count += log.count;
    }else{
      if(acc.count > acc.maxCount){
        acc.maxCount = acc.count;
        acc.index = index;
      }
      acc.count -= log.count;
    }
    return acc;
  }

  let {index} = logs.reduce(analyzeLogEntry,{count:0, maxCount: 0});
  return [logs[index-1].timestamp,logs[index].timestamp];
}


Refactoring code to implement clean code using repositories

You are close. The only thing that jumps out at me is your use of the MembershipFormRepository type instead of the IMembershipFormRepository interface. This prevents you from being able to test consumers of it easily. For example, consider this case:

You have an object of type Foo that takes an injected instance of type Bar that takes an injected instance of a DB context context. You want to test that something on the Foo type works. Here is your test setup:

var dbContext = new Moq<DbContext>();
dbContext
    .Setup(s => s.Get())
    .Returns(new List<Item>());

var bar = new Bar(dbContext.Object);
var foo = new Foo(bar);

// assert foo.DoSomething()

Notice how you have to mock up a full Bar object, and even more troublesome, rely on Bar working correctly, for the test to pass. If Bar has a bug, your test can fail; this test, because it tests Foo, should only fail if Foo has a bug. If you injected a type of IBar into the Foo instead, you could mock that, instead of the DB context:

var bar = new Moq<IBar>();
bar.Setup(s => s.GetItems())
   .Returns(new List<Item>());

var foo = new Foo(bar.Object);

// assert foo.DoSomething()

Now, instead of relying on Bar.GetItems not being buggy, you just create a mocked object that always returns the same data. This test also won't fail if Bar changes. The first test would fail if you changed Bar.GetItems to call DbContext.Where instead of DbContext.Get because you hadn't mocked the Where call, which would once again falsely report a bug in the Foo type because the Bar type had changed or was buggy.


Calculating the factorial of a number efficiently

How can I improve the runtime? What are more efficient algorithms to calculate the factorials of a large number?

If you really want to know it, then study BigIntegerMath.factorial from Guava. There are too many tricks there to be described here.

Review

// TODO Auto-generated method stub

Are you sure you need it?

    boolean oddUptoValue=false;
    int tempUptoValue=0;
    if(uptoValue%2!=0){
        tempUptoValue=uptoValue-1;
        oddUptoValue=true;
    }else{
        tempUptoValue=uptoValue;
    }

Too complicated. What about

boolean oddUptoValue = uptoValue % 2 != 0;

and leaving oddUptoValue alone, as the division by two rounds down anyway.

int temp=(tempUptoValue-i+1)*i;

This can overflow, use

long product = (tempUptoValue - i + 1L) * i;

Note the name, the formatting (spacing), and the use of 1L which enforces a cast to long of both multiplicands.

 answer=answer.multiply(new BigInteger(String.valueOf(temp)));

This should be

 answer = answer.multiply(BigInteger.valueOf(product));

Optimizations

Despite avoiding the conversion via string being much faster, my above changes won't help with speed. The vast majority of the time for big inputs get spend in the BigInteger multiplication.

The simplest trick is getting rid of powers of two. Use Integer.numberofTrailingZeros for removing them from each multiplicand, compute the product and finally shift it left. This way the numbers you deal with get smaller and all operations get faster.

Regrouping the operands is the second trick. For four about equally big numbers, computing

(a * b) * (c * d)

instead of

((a * b) * c) *d

gives you a nice speedup. You can regroup your operands to make use of this.


My main complaint about your code is that you rebuild the table used for translation for each and every character you are encoding or decoding. This is a major waste of computational power. In addition I've got some other minor comments:

Why the throws SomeException?  – Do you really need these, as you don't explicitly throw them from your code? I'm not entirely sure on common or best practices here, so this might be a moot point, but couldn't these be removed in your code?
Add more space – The density of your code, makes it harder to read. Add a little vertical space here and there, and it will look a lot better. Consider opening your methods with a newline, so that the signature doesn't interfere with the start of the method.
How to access the ch from the properties – In the properties file, you have an entry for ch. How do get to this one? Or is this at typo?

Also adding space before for loop or if blocks, helps structuring the code within a method. Finally, adding an extra newline so that it is two newlines between methods helps separate the methods.
Most variables are named well – Mostly good naming, but input is kind of vague. I would prefer text in encode() and morseCode in decode(), and avoid the lowerCaseInput. Having a variable name describing what has happened to it, seems a little strange.

Avoiding the getMorseCode() rebuild

You're in a class, and a class can have a constructor. Utilize this to build the needed HashMap. And instead of having a rather costly getKeyByValue() I would advice in this case duplicate the reverse map, as well. (Another option would be to use some external library to implement some bidirectional map, like the BiMap from the Guava library). This would lead to code resembling this untested code:

public class Coder {
  private HashMap <String, String> encodeMap;
  private HashMap <String, String> decodeMap;

  Coder() {
      this("morse_code.properties");
  }

  Coder(String filename) {
    InputStream input = null;
    Properties properties = new Properties();
    try {
      input = Morse.class.getClassLoader().getResourceAsStream(filename);
      if (input == null) {
        System.out.println("Sorry, unable to find " + filename);
        return; // Or throw bad exception... :-)
      }

      encodeMap = new HashMap<>();
      decodeMap = new HashMap<>();

      properties.load(input);

      for (String text : properties.stringPropertyNames()) {
        String morseCode = properties.getProperty(text);
        encodeMap.put(text, morseCode);
        decodeMap.put(morseCode, text);
      }

    // Catch and cleanup, if needed...
    } catch (IOException ex) {
        ex.printStackTrace();

    } finally{
      if (input!=null) {
        try {
            input.close();
              } catch (IOException e) {
                  e.printStackTrace();
            }
      }
    }
  }

  public final String encode(final String textInput) {

    StringBuilder encoded = new StringBuilder();
    int textLength = textInput.toLowerCase().length();

    for (int i = 0; i < textLength; i++) {
      String lookup = Character.toString(textInput.charAt(i));
      encoded.append(encodeMap.getOrDefault(lookup, " "));
      encoded.append("   ");
    }

    return encoded.toString();
  }

  public final String decode(final String morseInput) {

    StringBuilder decoded = new StringBuilder();

    for (String morseCode : morseInput.toLowerCase().split(" ")) {
      decoded.append(decodeMap.getOrDefault(morseCode, " "));
      decoded.append(" ");
    }
    return decoded.toString();
  }
}

Here I've also renamed the class to Coder, as it seemed kind of strange to use the Encode class to decode stuff... I've also removed some temporary variables to avoid clutter.

I also added a second constructor allowing for providing a different filename to the constructor. This way you could change the entire functionality of the encode/decode by providing a different properties file.

Code is untested as I don't have access to do the resources thingy using my online java compiler, but you'll get the gist of the idea.

PS! Using the try-with-resources as Vogel612 exemplifies in his answer, is most likely a better, more up to date way to do the properties reading.


Naming

Also the naming guidlines doesn't explictly mention variable local to a method, you should name them using camelCase casing.
Naming methods, properties and variables in a meaningful way will help you or Mr.Maintainer to faster grasp what a variable/method/class is about.
Shortening of names like foreach (string s in drwPaths) should be avoided.

General

If the right side type of an assignment is obvious one should use var like

var path = "C:\\Users\\SAFEROADS201\\Desktop\\01-VMS Trailer";

By using guard conditions you can save horizontal spacing which improves readability of the code.
By extracting the algorithm to a method in a separate class you can reuse it.
Filepaths should be composed using the System.IO.Path.Combine() method.
If you are dealing with a large amount of files you should prefer Directory.EnumerateFiles() over Directory.GetFiles().
From the documentation of GetFiles():

  The EnumerateFiles and GetFiles methods differ as follows: When you use EnumerateFiles, you can start enumerating the collection of names before the whole collection is returned; when you use GetFiles, you must wait for the whole array of names to be returned before you can access the array. Therefore, when you are working with many files and directories, EnumerateFiles can be more efficient.

variables should be declared as near as possible to their usage.
strings, especially strings which represents filepaths should be marked as verbatim string literal to ignore escape sequences. See this SO answer

Refactoring

Let us start by introducing a new class called SolidWorkFileConverter, add a constructor and add a method named ToPdf()

public class SolidWorkFileConverter
{
    private SldWorks swApplication;
    public SolidWorkFileConverter(SldWorks swApp)
    {
        swApplication = swApp;
    }

    public void ToPdf(string searchPath, string logFileName)
    {
        var logFileDestionation = System.IO.Path.Combine(searchPath, logFileName);
        var currentDate = DateTime.Now;
        var drawingFiles = System.IO.Directory.EnumerateFiles(Path, "*.slddrw", SearchOption.AllDirectories)
                                              .Where(file => !file.Contains("~$"));
        foreach (var drawingFile in drawingFiles)
        {
            ToPdf(drawingFile);
        }
        WriteToLog(logFileDestination, currentDate);
    }

    public void ToPdf(string drawingFile)
    {
        string destinationFileName = ComposeDestinationFileName(drawingFile);
        CreateDestinationDirectory(destinationFileName);
        int state = 0;
        int warningState = 0;
        ModelDoc2 swDoc = (ModelDoc2)(swApplication.OpenDoc6(s, 3, 0, "", ref state, ref warningState));
        state = swDoc.SaveAs3(pdfPath, 0, 0);
        swDoc = null;
        swApplication.CloseAllDocuments(true);
    }

    private string ComposeDestinationFileName(string sourceFileName)
    {
        return sourceFileName.Replace("Drawings", "PDFs").Replace("SLDDRW", "PDF");
    }

    private void CreateDestinationDirectory(string destinationFileName)
    {
        string directoryName = System.IO.Path.GetDirectoryName(destinationFileName);
        System.IO.Directory.CreateDirectory(directoryName);
    }

    private void WriteToLog(string logFileDestination, DateTime currentDate)
    {
        System.IO.File.WriteAllText(logFileDestination, currentDate.ToShortDateString());
    }
}

this can now be called by your main() method (or used anywhere) like

string searchPath = @"C:\Users\SAFEROADS201\Desktop\01-VMS Trailer";
string logFileName = System.IO.Path.Combine(searchPath , "UpdatedPDFs.txt");
SolidWorkFileConverter converter = new SolidWorkFileConverter(swApp);
converter.ToPdf(searchPath, logFileName);


I'm not sure if I'd use the phrase "too many", but I think you've included a header or two you'd probably be better off without.

The most obvious example would be <cstring>. There's rarely a good reason to use any of the <cstring> functions in C++ code (and I don't see any hint that this code is one of the rare exceptions either).

Right now, the main (only?) thing I see you using from <cstring> is strstr. std::string has a find member that can find a substring like strstr does.
Your code also seems somewhat inconsistent, at least to me. For example, in one place you create a string with N repetitions of a single character using code like: std::string(character, repetitions). In another place you do roughly the same thing using a loop to append on underscore at a time. Since they're doing the same thing, it would be better for them to do it the same way (preferably the constructor for std::string).
Right now you use a string to hold a single character (and enforce its being only one character). Since it's only a single char, I'd rather just use a char to hold it.
As a general rule of thumb, I'd prefer a well-chosen algorithm from the standard library over a raw loop.
Yes, you can (and in my opinion, should) break the code up into more functions (and based on your question, it seems like you already agree, but may not be sure how to do it).
I'd generally prefer to use the new random-number generation routines in <random> over the srand/rand from the C library. Likewise, I'd rather use the distribution classes in the standard library over the rand() % total_lines you have now. (but in fairness, they are more work to use, and it's unlikely to make a difference anybody's likely to notice or care about (but in many other cases, it's more important).
I'd avoid using namespace std; I know at first it seems painful to type in std:: everywhere, but it's still better than using namespace std;.
There are also neater ways to read words from a file into an array of strings, such as:

std::ifstream infile("wordlist.txt");

std::vector<std::string>{std::istream_iterator<std::string>(infile), {}};

One point though: this will produce different results if your input file has multiple words on one line. In this case your code treats a whole line as one word, but this treats each word separately.
I generally advise against using std::endl. It's probably harmless in this case, but a habit I'd try to avoid anyway.


Well, as far as I see it, I can't see another way of listing what you're using. But as you're using JOIN, I would make sure that your columns have the right indexes there, or it'll be very slow when your database grow up.

About INNODB: It depends on your database, and what you're doing with the data, but the good thing about INNODB is that if you have that table engine you can make use of Transactions, and will be easier to make a backup of your live databases if that is the engine selected. And also, if your engine is INNODB, you can use foreign keys to keep your data synchronized  (for example, you can restrict the delete of a user if the id is in another table, or not allowing insert a player id if that id doesn't exist).

If you're not planning using transactions neither foreign keys, and your tables are going to perform way more read operation than modify operations (create/update) usually MyISAM is faster, but if you have to modify the rows and read at the same time, is going to be better INNODB because when reading/modifying it only locks the row that is using, while MyISAM locks the whole table. When you'll have heavy load and read/write at the same time, MyISAM will be slower. Anyway, don't trust me: Test it by yourself performing load testing on your application, that's the way to go.

And lately, about your code: Don't mix connection, SQL and show the presentation on the same file, or it'll be hard to you later make the code maintenance. I would suggest you divide that code into classes, so you can retrieve the data from a model class, and show them in a template. Read From flat PHP to Symfony 2, which is quite good and may help you a lot with the concept. Although is Symfony2, the main point is grab the idea and try to separate the code concepts as much as possible, trying to reuse it.


Passing connection for multiple classes/methods

It may make sense to organize your objects in a different way.  With Read and Write extending Connect, you are basically treating them as if they are connections rather than being operations performed over a connection.

I think the most straightforward way to model operations over a connection would be something like this:

public static class GameConnection {
    private TCPMasterConnection conn;

    public void connectTo(String ipAddress, int port) throws IOException {
        conn = new TCPMasterConnection(InetAddress.getByName(ipAddress));
        conn.setPort(port);
        conn.connect();
    }

    public int[] read(int unitID, int startAddress, int count) throws IOException {
        // Do the read over this.conn
    }

    public int[] write(int unitID, int startAddress, int dataToWrite, int count) throws IOException {
        // Do the write over this.conn
    }

    public void close() throws IOException {
        conn.close();
    }
}

To use it, you then just

    GameConnection conn = new GameConnection();

    conn.connectTo("127.0.0.1", 8080);
    int[] readStuff = conn.read(1, 2, 3);
    int[] writeStuff = conn.write(1, 2, 3, 4);
    doSomeOtherThingsWithIt(conn);
    conn.close();

For more abstraction, you could make the GameConnection an interface and have different implementations for different transport protocols.


This looks to do the job. I would only change the variable naming to be more meaningful in this context to guess for user guess and answer for the generated number.
I would also try to handle erroneous input such as strings instead of numbers being passed.
But besides this is still functionally good :D