DEV Community: Istiaq Nirab

Five steps from a business problem to an LLM that actually ships

Istiaq Nirab — Fri, 02 Oct 2026 22:23:02 +0000

Most LLM projects I have watched go sideways did not fail on the model. They failed because somebody picked the model first.

That is the whole pathology. A team reads a benchmark table, decides on a model, and only then goes looking for a problem shaped like it. Six weeks later there is a demo nobody can price, evaluate, or hand to the support team. The work was real. The order was wrong.

There is a sequence that avoids this, and it is not complicated: understand, prepare, select, customize, productionize. Five steps. The model choice sits in the middle, not at the front, and by the time you get there the decision is mostly made for you.

1. Understand

Before anything else, write down what the business actually wants and how you will know if you got it.

Two things belong here that teams usually skip.

Separate model metrics from business metrics. Model-centric metrics are the ones your notebook prints: accuracy, F1, perplexity, BLEU, exact match. Business-centric metrics are the ones your director cares about: tickets deflected, hours saved per analyst, invoices processed without human touch, revenue per session. They are not the same number and they do not always move together. I have seen a classifier gain four points of F1 and deflect fewer tickets, because the gain came entirely on a class that was never routed to a human anyway.

Pick both. The model metric is how you steer during development. The business metric is how you decide whether the thing was worth building.

Look at the data before you promise anything. Quantity, quality, format. Two thousand labelled examples is a different project from twenty. A folder of scanned PDFs is a different project from a clean database export. If the labels came from three different people over two years with no guidelines, you have a labelling project first and an LLM project second.

Then the non-functionals, which is where most of the honest constraints hide:

Cost per call, and calls per day. A tenth of a cent is nothing until it runs forty thousand times a day.
Latency. Something a user waits for behaves differently from something that runs overnight.
Scale. Peak concurrency, not average.
Data residency and privacy. This one quietly eliminates entire vendors, so find out on day one rather than day sixty.
Budget and timeline. Both the build and the running cost, which are separate budgets and often separate owners.

If you cannot fill in this section, you are not ready to evaluate anything. You are still doing discovery, and that is fine — just call it what it is.

2. Prepare

Now you go looking, and the first thing to look for is whether you need an LLM at all.

Research existing and non-LLM solutions. A regular expression, a lookup table, a gradient-boosted tree over tabular features, a vendor product someone already licensed. This is not pessimism about LLMs. It is that you need a baseline, and a boring baseline is the most useful object in the whole project. It tells you what "good" costs today. Every later decision gets measured against it. If logistic regression over TF-IDF gets you 88% and the LLM gets you 91%, that three points has a price, and someone other than you should decide whether to pay it.

Then compare candidate models on the boring attributes first. Context length, price per million tokens in and out, licence, whether you can self-host, rate limits, how long the provider supports a version before deprecating it. These are facts. They are also usually enough to cut a list of twenty models to four.

Then benchmarks, leaderboards and arenas — with a healthy suspicion. Public benchmarks are contaminated, leaderboards drift, and arena rankings measure what humans prefer in a chat window, which may have nothing to do with extracting line items from a purchase order. Use them to shortlist. Never use them to decide. The score that matters is the one your candidates get on your data, and you are about to build that.

Curate the data: clean, preprocess, split. Even in a prompting-only project you need a held-out evaluation set. Especially in a prompting-only project, because prompt iteration overfits to whatever examples you keep staring at. Freeze a test set now, before you have opinions about it, and do not look at it again until the end.

A hundred well-chosen examples that cover your real edge cases beat ten thousand scraped rows. Pull the weird ones deliberately: the empty input, the wrong language, the customer who pasted their entire email thread, the malformed number format that only the Belgian office uses.

3. Select

This is the step everyone thinks is the whole project, and by now it is almost mechanical.

Take your shortlist. Run it against the evaluation set you just froze. Compare against the boring baseline. Include the cheap small model even when you are sure it will lose — it wins often enough to be worth the twenty minutes, and when it loses you get a defensible reason to spend more.

Two habits worth keeping:

Log every run. Model version, prompt version, parameters, cost, latency, the actual outputs. Three weeks from now someone will ask why you chose this one, and "I remember it being better" is not an answer. Model versions also shift under you; without a log you cannot tell a regression from a memory.

Do not select a single model reflexively. Routing is a legitimate design: a small fast model handles the 80% of easy cases, a larger one takes the rest. Cost drops sharply, and you need a confidence signal to route on anyway.

If you are fine-tuning, this is where you train and validate. If you are not, this is where you conclude you do not need to, which is a real outcome and worth stating out loud.

4. Customize

Four levers, and they are not equal. Three of them act at inference time, one at training time.

Prompting is first, always. It is the cheapest thing you can change and the fastest to test. Few-shot examples, an explicit output schema, a clear description of the role and the constraints. Teams routinely jump past this to fine-tuning and discover afterwards that a better prompt closed most of the gap for free.

RAG is the answer to "the model does not know our stuff". Retrieval puts the relevant document in front of the model at the moment it answers. It is what you want for knowledge that changes — policies, prices, product docs, tickets — because updating an index is trivial and retraining is not. Most RAG disappointments are retrieval disappointments: the model answered fine given what it was handed, and what it was handed was the wrong three chunks.

Agents let the model take actions in a loop: call a tool, read the result, decide what to do next. Right for tasks with genuine branching, where the sequence of steps depends on what you find. Wrong, and expensive, for anything you could have written as a fixed pipeline. If you can draw the flowchart, write the flowchart.

Fine-tuning is the only one that changes the model's weights, and the only one that happens at training time rather than inference time. It is the right tool for form — consistent tone, a rigid output format, a domain's vocabulary and conventions. It is a poor tool for facts, because retraining to update a fact is absurd when an index update does the same job in seconds. It also gives you a model you now own the lifecycle of: versions, retraining, drift, storage. That is not a reason to avoid it. It is a reason to be sure the first three levers were not enough.

The order is deliberate. Prompt, then retrieve, then add agency, then fine-tune. Each step up costs more to build and more to maintain, and each one is harder to undo.

5. Productionize

The gap between a working notebook and a working service is where most of the calendar actually goes.

Define the API between the model and everything else. A clean boundary — request in, structured response out — is what lets you swap models later without touching the product. You will swap models. Something cheaper or better ships every few months, and a team that wired the provider SDK directly into three controllers cannot take advantage of it.

Decide hosting and deployment. Vendor API, managed endpoint, or your own GPUs. This follows from step 1's non-functionals, not from preference. Data residency, latency floor and volume decide it between them.

Handle the operational surface. Scaling and queueing under burst. Timeouts and retries, because providers do fail. Monitoring on latency, error rate and spend, with an alert on spend specifically — a retry loop against a metered API is an expensive kind of bug. Security around prompt injection, especially anywhere the model output feeds something that executes. Compliance and audit logging. Observability that captures inputs and outputs, so that when someone reports a bad answer you can find the request rather than guessing.

Run evals against the business metrics from step 1. This is what closes the loop. Not the offline F1 you tracked during development — the tickets deflected, the hours saved, the invoices cleared. Model-metric dashboards look reassuring and tell you very little about whether the project earned its keep.

Then keep measuring. Inputs drift, providers update models beneath you, and the thing that worked in March quietly degrades by September. Schedule the re-evaluation. Set a threshold that triggers a look. Retrain or re-tune when it fires, not when someone happens to notice.

The part that matters

Read the five steps back and notice what the first one and the last one have in common. Step 1 defines the business metric. Step 5 measures it. Everything in between is machinery.

That is the actual discipline here. The strategy is not really about selecting a model — the model tends to fall out of the constraints once you have written them down honestly. It is about deciding in advance what success means, in terms the business recognises, and then being willing to check.

Skip step 1 and you will still ship something. You just will not be able to tell anyone whether it worked.

N-grams: the language model before language models

Istiaq Nirab — Wed, 30 Sep 2026 07:08:02 +0000

Before transformers, before word embeddings, before anyone said "attention is all you need", autocomplete worked. Your phone guessed the next word. Search engines finished your query. Spell checkers knew that "definately" was wrong and "definitely" was right.

All of that ran on counting.

An N-gram is a continuous sequence of N items pulled from a text. The items are usually words, sometimes characters. That is the entire idea. Everything else in this post is a consequence of it.

Splitting a sentence

Take a sentence:

I love programming

Slide a window of size N across it, one position at a time, and collect what the window sees.

Unigrams (N = 1) — the window holds one word:

["I", "love", "programming"]

Bigrams (N = 2) — two words:

["I love", "love programming"]

Trigrams (N = 3) — three words:

["I love programming"]

A sentence of L words yields L - N + 1 N-grams. Three words with a window of two gives two bigrams. Three words with a window of three gives one trigram. Push N to four and you get nothing at all, because the window is wider than the sentence.

In Python the whole operation is one line:

def ngrams(tokens, n):
    return [tuple(tokens[i:i + n]) for i in range(len(tokens) - n + 1)]

tokens = "I love programming".split()
ngrams(tokens, 2)
# [('I', 'love'), ('love', 'programming')]

nltk ships the same thing as nltk.util.ngrams, and scikit-learn exposes it as the ngram_range argument on CountVectorizer and TfidfVectorizer. You rarely need to write it yourself, but it helps to know there is nothing hiding under the hood.

Why bother

A unigram model sees a document as a bag of loose words. "Dog bites man" and "man bites dog" are identical to it. Both are the same three words with the same counts, and the model has no way to tell a headline from its opposite.

Bigrams fix that specific failure. "Dog bites" and "bites dog" are different keys in the count table, so word order finally means something. Trigrams capture a little more: negation attaches ("not good" stops looking like praise), and fixed phrases hold together ("machine learning" is one concept, not two words that happen to be adjacent).

So N-grams buy you three things:

Word order, within the width of the window.
Local context, again only as wide as the window.
Common phrase patterns, because frequent sequences accumulate high counts.

Notice how often the phrase "within the window" shows up. That constraint is the whole story of N-grams, and it comes back at the end of this post.

Turning counts into predictions

Counting sequences is descriptive. To predict, you turn counts into probabilities.

The goal of a language model is to score a sentence: how likely is this string of words? The chain rule of probability breaks that into a product of next-word probabilities.

P (w_{1}, w_{2}, \dots, w_{n}) = P (w_{1}) \cdot P (w_{2} ∣ w_{1}) \cdot P (w_{3} ∣ w_{1}, w_{2}) \dots

That last term is the problem. Conditioning on every previous word means you would need to have seen that exact prefix before, and for any sentence longer than a few words you never have.

The N-gram model makes an assumption to escape this, called the Markov assumption: only the last N-1 words matter. A bigram model throws away everything except the immediately preceding word.

P (w_{n} ∣ w_{1}, \dots, w_{n - 1}) \approx P (w_{n} ∣ w_{n - 1})

That approximation is wrong, and it is wrong on purpose. It is wrong in a way that makes the whole thing computable, because now the probability is just a ratio of two counts you can actually collect:

P (programming ∣ love) = \frac{count ( love programming )}{count ( love )}

If "love" appears 10,000 times in your corpus and "love programming" appears 40 of those, the probability is 0.004.

Prediction, concretely

You type:

I love

A bigram model looks up every continuation it has ever seen after "love", ranked by count:

Continuation	Count	Probability after "love"
love you	820	0.082
love it	610	0.061
love this	450	0.045
love programming	40	0.004
love pizza	35	0.0035

It suggests the top of that list. That is old autocomplete, and it is also, structurally, what a modern language model does at the last step. The difference is entirely in how the distribution gets computed, not in what happens once you have it.

A minimal implementation:

from collections import defaultdict, Counter

model = defaultdict(Counter)

for sentence in corpus:                    # corpus = list of token lists
    for w1, w2 in ngrams(sentence, 2):
        model[w1][w2] += 1

def predict(word, k=3):
    total = sum(model[word].values())
    return [(w, c / total) for w, c in model[word].most_common(k)]

predict("love")
# [('you', 0.082), ('it', 0.061), ('this', 0.045)]

Roughly fifteen lines, and you have a working language model. Train it on a large enough corpus and the suggestions stop looking random.

Choosing N

N is a dial between two failure modes, and there is no setting that avoids both.

Small N generalises well and predicts poorly. A bigram model has seen almost every word pair it will encounter, so it rarely draws a blank. But it barely knows anything about what it is generating. Sampling from a bigram model produces text that is locally plausible and globally nonsense: each pair of adjacent words looks fine, and the sentence as a whole means nothing.

Large N predicts sharply and generalises terribly. A 5-gram model that has seen your exact four-word prefix gives an excellent guess. Most of the time it has not seen it, and it has nothing to say.

The counts make the tradeoff obvious. With a vocabulary of 50,000 words, there are $2.5 \times 1 0^{9}$ possible bigrams and $1.25 \times 1 0^{14}$ possible trigrams. No corpus covers a meaningful fraction of that space. Trigrams are the usual compromise for word-level models. Character-level N-grams can go much higher, often 4 to 6, because the alphabet is tiny and the space stays manageable.

The sparsity problem

Here is where the counting approach starts to strain.

Suppose your model has never seen "love debugging". The count is zero, so the probability is zero. And because sentence probability is a product, one zero drags the entire sentence to zero. The model does not report low confidence in a plausible phrase. It reports that the sentence is impossible.

This is the data sparsity problem, and it is not an edge case. It is the normal condition. Most valid N-grams in any language never appear in any given corpus, because language is generative and corpora are finite.

The classical fix is smoothing: move a little probability mass away from things you have seen and give it to things you have not.

Add-one (Laplace) smoothing pretends every possible N-gram was seen one extra time:

P (w_{2} ∣ w_{1}) = \frac{count ( w _{1} , w _{2} ) + 1}{count ( w _{1} ) + V}

$V$ is the vocabulary size. Nothing is zero anymore. It is also crude, since it hands the same mass to every unseen sequence, and with a large vocabulary it steals far too much from the sequences you actually observed.

Backoff is smarter. If the trigram is missing, fall back to the bigram. If that is missing too, fall back to the unigram. Use the most specific evidence you have, and degrade gracefully instead of collapsing.

Interpolation blends all the orders at once rather than choosing between them:

P^(w_{3} ∣ w_{1}, w_{2}) = λ_{1} P (w_{3} ∣ w_{1}, w_{2}) + λ_{2} P (w_{3} ∣ w_{2}) + λ_{3} P (w_{3})

with the weights $λ_{1} + λ_{2} + λ_{3} = 1$ , usually tuned on held-out data.

Kneser-Ney smoothing is what serious N-gram systems actually used. Its insight is that raw frequency is the wrong signal for a backoff estimate. The word "Francisco" is common, but it appears almost exclusively after "San". It is a bad guess in a novel context despite its frequency. Kneser-Ney backs off on how many distinct contexts a word appears in, not how often it appears. It was the state of the art in statistical language modelling for well over a decade.

Measuring the model

The standard metric is perplexity: the inverse probability the model assigns to a test set, normalised by length.

PP (W) = P (w_{1}, w_{2}, \dots, w_{n})^{- \frac{1}{n}}

Read it as the model's average branching factor. A perplexity of 100 means the model is, on average, as uncertain as if it were choosing uniformly among 100 words at each position. Lower is better.

Word-level trigram models with good smoothing land somewhere around 100 to 200 perplexity on standard English benchmarks. Modern neural models sit well under 20 on the same data. That gap is the entire argument for what came next.

One rule that trips people up: always compute perplexity on held-out text. A model evaluated on its training corpus scores beautifully and tells you nothing, because it has memorised the answers.

Where N-grams still show up

The N-gram language model is largely historical. The N-gram feature is alive and working in production everywhere.

Text classification. Feeding unigrams plus bigrams into a TfidfVectorizer and training logistic regression or a linear SVM on top is still a genuinely strong baseline for spam detection, sentiment, and topic labelling. It trains in seconds, it needs no GPU, and it is fully interpretable. You can point at the exact bigram that pushed a document into a class. Build this before you reach for a transformer, so you know what the transformer has to beat.

from sklearn.feature_extraction.text import TfidfVectorizer

vec = TfidfVectorizer(ngram_range=(1, 2), min_df=2)
X = vec.fit_transform(documents)

Search and autocomplete. Query suggestion still leans heavily on N-gram frequency from query logs. It is fast, it reflects what people actually type, and it needs no inference server.

Spell correction. Context-sensitive correction is an N-gram job. Deciding between "their" and "there" means comparing the probability of the surrounding trigrams.

Machine translation evaluation. BLEU, the metric that dominated translation research for twenty years, is N-gram precision overlap between the candidate and the reference. ROUGE does the same for summarisation.

Tokenisation itself. Byte Pair Encoding, which feeds essentially every modern LLM, builds its vocabulary by repeatedly merging the most frequent adjacent character pair. That is character bigram counting, running inside the models that supposedly replaced N-grams.

Plagiarism and near-duplicate detection. Shingling documents into character or word N-grams and comparing the sets, usually with MinHash, is the standard approach.

Language identification. Character trigram profiles separate languages remarkably well, and the classifier fits in a few kilobytes.

The limitation that ended the era

Everything an N-gram model knows lives inside a window of N-1 words. Move a dependency outside that window and the model cannot see it.

The keys that I left on the kitchen counter yesterday afternoon ___

The verb has to agree with "keys", which is ten words back. A trigram model sees "yesterday afternoon" and nothing else. It has no mechanism for reaching further, because reaching further is precisely what the Markov assumption gave up in exchange for being computable.

There is a second, subtler failure. N-grams treat every sequence as an opaque symbol. To the model, "the cat sat" and "the dog sat" are two unrelated keys in a hash table. It learns nothing about the first from the second. There is no notion that "cat" and "dog" are similar, so evidence never transfers between related words. Every sequence has to be observed independently, which is exactly why sparsity bites so hard.

Neural language models attacked both problems at once. Embeddings replaced discrete symbols with dense vectors, so similar words occupy nearby positions and evidence generalises across them. Recurrent networks, and later attention, replaced the fixed window with a learned, unbounded reach over the context. Attention in particular lets position 400 look directly at position 12, which no amount of tuning N will ever do.

What to take from it

N-grams are worth understanding in 2026 for reasons that have nothing to do with using them as a language model.

They make the shape of language modelling visible. Predicting the next token from context, scoring a sequence with a product of conditional probabilities, evaluating with perplexity, fighting the tension between memorisation and generalisation. All of it is right there in fifteen lines of Python you can read in one sitting. The same structure sits inside a transformer, buried under a great deal of machinery.

They are also still the right tool often enough to matter. When you need a classification baseline this afternoon, or a spell checker that runs on a device with no network, or a metric that anyone can reimplement, counting sequences is not a compromise. It is the correct choice.

The lesson is not that counting was replaced. It is that counting could only ever see as far as its window, and that seeing further turned out to be what mattered most.

vsCode Configuration for WordPress Plugin

Istiaq Nirab — Tue, 20 Dec 2022 03:58:37 +0000

First of all you need to install wpcs dependencies on your plugin via composer :

composer require --dev wp-coding-standards/wpcs:dev-develop

After install this package, you'll get access these two types of commands :

# check php coding standard releted issues

./vendor/bin/phpcs

# fix coding standard automatically

./vendor/bin/phpcbf

I recommend to register these commands with composer scripts.

"scripts": {
    "phpcs": "\"vendor/bin/phpcs\"",
    "phpcbf": "\"vendor/bin/phpcbf\"",
    "sniffs": "\"vendor/bin/phpcs\" -e",
}

then you can easily access phpcs commands via composer:

composer phpcs
composer phpcbf
composer sniffs

Extensions

Some vsCode extensions, I always use :

I recommend PHP Intelephense for PHP built-in functions completion, code completion (IntelliSense), go to definition support and many more.

phpcs extension allow us to display phpcs related issues without running phpcs commands every time & also fix coding styles after save file.

To enable WordPress coding standards:

"phpsab.standard": "WordPress",

It's automatically configure setup from your root project composer.json.

But what happen if you want to develop something like WooCommerce Extension OR any other plugin based plugin !!

You need to open wordpress plugins directory instead of opening single plugin directory.

Then you can get better code completion (IntelliSense) support.

But the phpcs extension doesn't work, you need to configure locally in the plugins directory. So, create new folder called .vscode under the project root and create settings.json file here.

Inside settings.json :

{
  "phpsab.executablePathCS": "./subscription-pro/vendor/bin/phpcs",
  "phpsab.executablePathCBF": "./subscription-pro/vendor/bin/phpcbf",
  "phpsab.standard": "WordPress",
  "[php]": {
    "editor.defaultFormatter": "valeryanm.vscode-phpsab"
  }
}

Now, you can see phpcs working fine.

The last extension is WordPress Hooks IntelliSense, which will provide better autocompletion for hooks.

Thanks.

VSCode Clean & Minimal Setup

Istiaq Nirab — Mon, 24 Aug 2020 02:41:18 +0000

VSCode ( default Theme )

VSCode ( MonoKai Pro Theme )

VSCode ( Noctis Theme variations )

Setup

settings.json

{
  "editor.fontSize": 13,
  "editor.fontFamily": "Operator Mono",
  "editor.lineHeight": 40,
  "editor.minimap.enabled": false,
  "editor.scrollbar.horizontal": "hidden",
  "editor.scrollbar.vertical": "hidden",
  "editor.lineNumbers": "off",
  "editor.wordWrap": "on",
  "editor.renderLineHighlight": "none",
  "editor.renderIndentGuides": false,
  "editor.overviewRulerBorder": false,
  "workbench.editor.showTabs": false,
  "editor.hideCursorInOverviewRuler": true,
  "workbench.tree.renderIndentGuides": "none",
  "breadcrumbs.enabled": false,
  "workbench.statusBar.visible": false,
  "workbench.activityBar.visible": false,
  "workbench.startupEditor": "newUntitledFile",
  "window.nativeTabs": true,
  "workbench.iconTheme": "Monokai Pro Icons",
  "workbench.sideBar.location": "right",
  "git.enabled": false,
  "workbench.colorTheme": "Monokai Pro"
}

keybindings.json

// Place your key bindings in this file to override the defaults
[
  {
    "key": "cmd+t",
    "command": "workbench.action.terminal.toggleTerminal"
  },
  {
    "key": "ctrl+`",
    "command": "-workbench.action.terminal.toggleTerminal"
  },
  {
    "key": "delete",
    "command": "workbench.action.closeAllEditors"
  },
  {
    "key": "cmd+k cmd+w",
    "command": "-workbench.action.closeAllEditors"
  }
]

open other file from tabs ( ctrl + Tab )

toggle file explorer ( ⌘ + B )

Thanks

Feel free to ask any questions about my setup & Also share your setup too !!

Uses of array_combine function

Istiaq Nirab — Sun, 16 Aug 2020 11:31:17 +0000

array_combine is a inbuilt Function in PHP .

These function creates an array by using the elements from one keys array and one values array.

Example

<?php
    $a = array('green', 'red', 'yellow');
    $b = array('avocado', 'apple', 'banana');
    $c = array_combine($a, $b);

    print_r($c);
?>

Result

Array
(
    [green]  => avocado
    [red]    => apple
    [yellow] => banana

)

Thanks

PHP Array Count

Istiaq Nirab — Fri, 14 Aug 2020 20:42:23 +0000

By default PHP has two methods for count array.

array_count_values
count

array_count_values()

Using this function, the number of times a value in an array can be determined.

Example :

<?php
  $array = array(1, "hello", 1, "world", "hello");
  print_r(array_count_values($array));
?>

Result :

Array (
    [1] => 2
    [hello] => 2
    [world] => 1
)

count()

These function is very common & its return total amount of value from array .

<?php

 $array = array("a" => "green", "b" => "brown", "c" => 
  "blue", "red");
 echo count($array);

?>

Thanks

Uses of array_chunk function

Istiaq Nirab — Fri, 22 May 2020 22:04:39 +0000

array_chunk() is a build function in PHP.

Using this function, one or more new arrays are created with values of arrays. This function usually has 3 parameters.
But it is mandatory to use 2.

array – [array from which to extract values]
size – [key number of new arrays]
preserve_keys - [This value is FALSE by default, if TRUE, it will insert new arrays inside a new array]

Example – 1 :

<?php
    $array = array('a', 'b', 'c', 'd', 'e');
    print_r(array_chunk($array, 6));
?>

Result :

Array (     
 [0] => Array (             
   [0] => a             
   [1] => b             
   [2] => c             
   [3] => d             
   [4] => e         
  ) 
)

Example – 2 :

<?php
    $array = array('a', 'b', 'c', 'd', 'e');
    print_r(array_chunk($array, 2, true));
?>

Result :

Array (     
 [0] => Array (
   [0] => a             
   [1] => b         
 )
 [1] => Array (
   [2] => c
   [3] => d
 )
 [2] => Array (
   [4] => e
  )
)

Thanks 😊

Read Bangla :- https://nirab.xyz/post/uses-of-array_chunk-function/

Uses of array_column function PHP

Istiaq Nirab — Wed, 20 May 2020 14:30:51 +0000

PHP has a build function called array_column ()

Using this function a new array be created with the values of a certain key in a multi-dimension array.

The function has 5 parameters & 2 are mandatory to use.

input : Take value from the multidimensional array.
column_key : The value of the key for the index.
index_key : If you want to give a key to the index as a new array key. It is not mandatory to use it.

Example

<?php

$records = array(
    array(
        'id' => 2135,
        'first_name' => 'John',
        'last_name' => 'Doe',
    ),
    array(
        'id' => 3245,
        'first_name' => 'Sally',
        'last_name' => 'Smith',
    ),
    array(
        'id' => 5342,
        'first_name' => 'Jane',
        'last_name' => 'Jones',
    ),
    array(
        'id' => 5623,
        'first_name' => 'Peter',
        'last_name' => 'Doe',
    )
);

$first_names = array_column($records, 'first_name');
print_r($first_names);

?>

Result

Array (
 [0] => John     
 [1] => Sally     
 [2] => Jane     
 [3] => Peter 
)

Another example Using the index key,

Example

<?php

$records = array(
    array(
        'id' => 2135,
        'first_name' => 'John',
        'last_name' => 'Doe',
    ),
    array(
        'id' => 3245,
        'first_name' => 'Sally',
        'last_name' => 'Smith',
    ),
    array(
        'id' => 5342,
        'first_name' => 'Jane',
        'last_name' => 'Jones',
    ),
    array(
        'id' => 5623,
        'first_name' => 'Peter',
        'last_name' => 'Doe',
    )
);

$last_names = array_column($records, 'last_name', 'id');
print_r($last_names);

?>

Result

Array (     
 [2135] => Doe     
 [3245] => Smith     
 [5342] => Jones     
 [5623] => Doe 
)

Source Link :

https://www.php.net/manual/en/function.array-column.php

Thanks .

How To Change case of all keys in an array ?

Istiaq Nirab — Wed, 20 May 2020 13:57:22 +0000

How to modify the case of an array’s keys In PHP, there is a specific buildin function. Function name :

array_change_key_case()

This function have two parameters.

Array – [the array whose keys will be changed case by case],
Case Type – [In this case there will be 2 wells. Ex: CASE_UPPER and CASE_LOWER]

However, CASE_LOWER is set the case type by default.

Example

<?php
    $input_array = array("name" => 'Istiaq Nirab', "Age" => "18+");
    print_r(array_change_key_case($input_array, CASE_UPPER));
?>

Result

Array (
 [NAME] => Istiaq Nirab
 [AGE] => 18+
)

Thanks 😊